parsing a 3.1.0 spec schema puts single non-array value type into types array

[spacether]

High priority

swagger-parser version: 2.1.1
parsing a 3.1.0 spec schema puts single type into types array
When parsing the below spec, the first allof schema in AllofWithTheLastEmptySchema is defined as:

type: number

But the parser sets schema.type to null and loads that type into an array of length one in the types property.
A lot of existing code assumes that type will have a value for this use case.
This bug stops that code from working.
types going into the type or types property should be deterministic (should always behave the same way)
sometimes a single type is going into type
sometimes a single type is going into types (when not defined as an array of types)

See the schema's value here:

class JsonSchema {
    class Schema {
        type: [number]
        format: null
        $ref: null
        description: null
        title: null
        multipleOf: null
        maximum: null
        exclusiveMaximum: null
        minimum: null
        exclusiveMinimum: null
        maxLength: null
        minLength: null
        pattern: null
        maxItems: null
        minItems: null
        uniqueItems: null
        maxProperties: null
        minProperties: null
        required: null
        not: null
        properties: null
        additionalProperties: null
        nullable: null
        readOnly: null
        writeOnly: null
        example: null
        externalDocs: null
        deprecated: null
        discriminator: null
        xml: null
        patternProperties: null
        contains: null
        $id: null
        $anchor: null
        $schema: null
        const: null
        contentEncoding: null
        contentMediaType: null
        contentSchema: null
        propertyNames: null
        unevaluatedProperties: null
        maxContains: null
        minContains: null
        additionalItems: null
        unevaluatedItems: null
        _if: null
        _else: null
        then: null
        dependentRequired: null
        dependentSchemas: null
        $comment: null
        prefixItems: null
    }
}

spec:

openapi: 3.1.0
servers:
- url: https://someserver.com/v1
info:
  title: openapi 3.1.0 sample spec
  version: 0.0.1
  description: sample spec for testing openapi functionality, built from json schema
    tests for draft2020-12
tags: []
paths: {}
components:
  schemas:
    AllofWithTheLastEmptySchema:
      $schema: https://json-schema.org/draft/2020-12/schema
      allOf:
      - type: number
      - {}

[frantuma]

A lot of existing code assumes that type will have a value for this use case.
This bug stops that code from working.
types going into the type or types property should be deterministic (should always behave the same way)
sometimes a single type is going into type
sometimes a single type is going into types (when not defined as an array of types)

Current behavior is by design, it is deterministic and depends on the OAS version of the document, check this comment for details also about discouraged option since latest version to allow having type getter return single element , and this test demonstrating current behavior with your example doc.

Closing ticket, please reopen if you're still experiencing issues

P.S. marking with

High priority

and statements in bold might not help accelerating issue processing..

[spacether]

Thank you for the fix!

Sure thing. In the future I can not use that language and bold. How would you prefer that I and others convey that info?

[frantuma]

Thanks for editing the comment adding an appreciation line! It looks kind of nicer to me..

about the "conveyance" I would have some ideas and can share an example if needed, however the main point to me is that expressing whether the issue is important to yourself is perfectly fine, saying that an issue is a high priority to the maintainers of a repo is disrespectful as it implies that they must focus on and address it with haste.

The keyword here is Priority.

We appreciate that this library is important to you and are happy to look into issues as they arise. But we ask that you consider the tone of the issue both for us core maintainers and other folks who work on these projects.