Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"should be an array" error caused by misspelled "type" values #1832

Closed
hkosova opened this issue Jul 12, 2018 · 6 comments · Fixed by #1985
Closed

"should be an array" error caused by misspelled "type" values #1832

hkosova opened this issue Jul 12, 2018 · 6 comments · Fixed by #1985

Comments

@hkosova
Copy link
Contributor

hkosova commented Jul 12, 2018

Q&A (please complete the following information)

  • OS: Windows 7
  • Browser: Chrome 67
  • Method of installation: http://editor.swagger.io
  • Swagger-Editor version: 3.6.3
  • Swagger/OpenAPI version: 2.0

Example Swagger/OpenAPI definition:

swagger: '2.0'
info:
  title: test
  version: 0.0.0
paths: {}

definitions:
  Model1:
    type: int

Describe the bug you're encountering

A misspelled type value triggers an odd error

should be array

Expected behavior

No "should be array" error.

Screenshots

image

@shockey
Copy link
Contributor

shockey commented Apr 12, 2019

I've opened a pull request (#1985) that will close this issue.

Here's what Swagger Editor reports with my changes:

Structural error at definitions.Model1.type
should be equal to one of the allowed values
allowedValues: array, boolean, integer, null, number, object, string

@hkosova
Copy link
Contributor Author

hkosova commented Apr 12, 2019

@shockey

allowedValues: ..., null, ...

type cannot be null in OAS.

@shockey
Copy link
Contributor

shockey commented Apr 15, 2019

@hkosova, do you have a citation for that?

I'm seeing that OAS 2.0 indicates Schema.type as "taken directly from the [JSON Schema draft-04] definition and follow the same specifications".

JSON Schema, in turn, defines seven primitive types, including null.

Clarification would be a big help here. Thanks!

@hkosova
Copy link
Contributor Author

hkosova commented Apr 16, 2019

@shockey In case of OAS2, it's not mentioned in the OpenAPI Specification explicitly, but @webron explained later that type: null is not supported
OAI/OpenAPI-Specification#229 (comment)

@webron commented on Jun 25, 2015:
null is not a valid type as it is not listed in the spec. ... There's no full compliance with JSON Schema, and while the spec defers to JSON Schema in some sections, it also imposes limitations on others. If you feel there needs to be extra clarification on null not being usable anywhere, I'll be happy to clarify it in the spec itself.

@hkosova
Copy link
Contributor Author

hkosova commented Apr 16, 2019

Interesting... The official OAS2 schema imports the Schema.type definition from the JSON Schema schema

        "type": {
          "$ref": "http://json-schema.org/draft-04/schema#/properties/type"
        },

and the JSON Schema schema uses

    "definitions": {
        ...
        "simpleTypes": {
            "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ]
        },
        ...
        "type": {
            "anyOf": [
                { "$ref": "#/definitions/simpleTypes" },
                ...
            ]
        },

meaning the OAS2 schema does indeed (sort of) allow type: null.

Which might be an oversight of the part of OAS spec authors because other places in the OAS2 schema (e.g. queryParameterSubSchema.type) list the possible type values explicitly and there's no null type there.

@webron could you please clarify this?

@webron
Copy link
Contributor

webron commented Apr 16, 2019

null is not supported. The validation JSON Schema is not the source of truth. No null.

shockey added a commit to shockey/swagger-editor that referenced this issue Apr 17, 2019
shockey added a commit to shockey/swagger-editor that referenced this issue Apr 17, 2019
shockey added a commit to shockey/swagger-editor that referenced this issue Apr 17, 2019
shockey added a commit that referenced this issue Apr 18, 2019
* adopt @webron's OpenAPI 3.0 schema from OAI/OpenAPI-Specification#1270

permalink: https://github.com/OAI/OpenAPI-Specification/blob/92e15eba1d4591ebfe8c11898c48241e72854381/schemas/v3.0/schema.yaml

* add ajv-errors

* address error messages for #1808's Swagger 2.0 example

clarifies the schema and adds custom error messages for unclear error conditions

* address error messages for #1808's OpenAPI 3.0 example

* restrict underlying JSON Schema `type` field to simple types only (for #1832)

* fix limitation in JSON Pointer conversion helper

* add clear `not` error message (for #1489)

* add additionalProperties message (for #1394)

* add ajv-keywords

* use `switch` to intelligently identify inline vs referenced content (for #1853)

* use `switch` to XOR `schema` and `content` (for #1853)

* use `switch` to pivot security scheme based on type

(for #1672)

* use switch to fall-through to inline security scheme validation (for #1672)

* rewrite more Reference oneOfs (for #1519)

* add custom message for `Schema.required` type error (for #1519)

* rewrite Response/Reference oneOf (for #1489)

* use switch in ParameterLocation validation (for #1797)

* define pivot key switches for SecurityDefinitions (for #1711)

* give helpful `format: uri` messages for SecurityDefinitions (for #1711)

* eliminate NonBodyParameter; pivot on `Parameter.in` with a switch (for #1511)

* oneOf -> switch for Parameters.items reference

* (for #1711)

* remove redundant semantic validator (for #1511)

* adjust wording of custom error message (for #1853)

* add regression tests for all related issues

* revert to expect@^1.20.2

* linter fixes

* fix messaging flaw for #1832

* improve messaging for #1394

* use literal key for `$ref` in Reference Object

* remove commented legacy data from OAS3 schema

* remove superfluous quotation marks

* normalize test case paths to `/`

* normalize openapi fields to 3.0.0

* drop unused `paths` information

* ensure clear errors for 3.0 Parameter style/content exclusivity

* add `required` assertions to switch statements that pivot on a key's value

this prevents false positives when the pivot key is missing entirely

* remove stray space
shockey added a commit to shockey/swagger-editor that referenced this issue May 23, 2019
…i#1985)

* adopt @webron's OpenAPI 3.0 schema from OAI/OpenAPI-Specification#1270

permalink: https://github.com/OAI/OpenAPI-Specification/blob/92e15eba1d4591ebfe8c11898c48241e72854381/schemas/v3.0/schema.yaml

* add ajv-errors

* address error messages for swagger-api#1808's Swagger 2.0 example

clarifies the schema and adds custom error messages for unclear error conditions

* address error messages for swagger-api#1808's OpenAPI 3.0 example

* restrict underlying JSON Schema `type` field to simple types only (for swagger-api#1832)

* fix limitation in JSON Pointer conversion helper

* add clear `not` error message (for swagger-api#1489)

* add additionalProperties message (for swagger-api#1394)

* add ajv-keywords

* use `switch` to intelligently identify inline vs referenced content (for swagger-api#1853)

* use `switch` to XOR `schema` and `content` (for swagger-api#1853)

* use `switch` to pivot security scheme based on type

(for swagger-api#1672)

* use switch to fall-through to inline security scheme validation (for swagger-api#1672)

* rewrite more Reference oneOfs (for swagger-api#1519)

* add custom message for `Schema.required` type error (for swagger-api#1519)

* rewrite Response/Reference oneOf (for swagger-api#1489)

* use switch in ParameterLocation validation (for swagger-api#1797)

* define pivot key switches for SecurityDefinitions (for swagger-api#1711)

* give helpful `format: uri` messages for SecurityDefinitions (for swagger-api#1711)

* eliminate NonBodyParameter; pivot on `Parameter.in` with a switch (for swagger-api#1511)

* oneOf -> switch for Parameters.items reference

* (for swagger-api#1711)

* remove redundant semantic validator (for swagger-api#1511)

* adjust wording of custom error message (for swagger-api#1853)

* add regression tests for all related issues

* revert to expect@^1.20.2

* linter fixes

* fix messaging flaw for swagger-api#1832

* improve messaging for swagger-api#1394

* use literal key for `$ref` in Reference Object

* remove commented legacy data from OAS3 schema

* remove superfluous quotation marks

* normalize test case paths to `/`

* normalize openapi fields to 3.0.0

* drop unused `paths` information

* ensure clear errors for 3.0 Parameter style/content exclusivity

* add `required` assertions to switch statements that pivot on a key's value

this prevents false positives when the pivot key is missing entirely

* remove stray space
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants