Nullable object property fails to validate `null`

Describe the bug

I’m working with an API that requires differentiating between properties that are T | undefined or T | null.

In OpenAPI 3.0, T | null properties seem to be modelled like:

schemas:
  TestObject:
    type: object
    properties:
      otherObjectMaybeNullA:
        $ref: "#/components/schemas/OtherObject"
        nullable: true
      otherObjectMaybeNullB:
        anyOf:
        - $ref: "#/components/schemas/OtherObject"
        nullable: true
    required:
    - otherObjectMaybeNullA
    - otherObjectMaybeNullB

  OtherObject:
    type: object

In both cases the validator does not accept null as a valid value. Errors are 'should be object' and 'should match some schema in anyOf'.

To Reproduce

Validate above against { otherObjectMaybeNullA: null, otherObjectMaybeNullB: null }.

Actual behavior

Validation fails.

Expected behavior

Validation should pass.

Examples and context

See above.

[dotMortis]

@cdimascio

v4.5.0

Nullable objects can’t be validated if properties are defined in the openapi.json.

This one works (nestedObject can be null or object)

ObjectOne:
  type: object
  additionalProperties: false
  required: 
    - id
    - username
  properties:
    id:
      type: string
      format: uuid
      readOnly: true
    username:
      type: string
    nestedObject:
      nullable: true
      type: object

This one can’t be null (error: .response.ObjectOne.nestedObject should be object)

ObjectOne:
  type: object
  additionalProperties: false
  required: 
    - id
    - username
  properties:
    id:
      type: string
      format: uuid
      readOnly: true
    username:
      type: string
    nestedObject:
      nullable: true
      type: object
      required:
        - name
        - id
      properties:
      	id:
          type: string
          format: uuid
        name:
          type: string

[bluenote10]

Thanks for looking into this! Yes, that seems to be a bit of a mess in OpenAPI 3.0. My interpretation of Clarify Semantics of nullable in OpenAPI 3.0 was that at least the second form is valid. Other indicators:

• The online swagger validator shows the second form as valid, and actually outputs a warning for the first case to change it into the second form.
• When I raised the same issue for swagger-typescript-api support for both forms was added.

Looks like I’m a bit stuck in terms of work-arounds because:

• I can’t migrate to OAS 3.1.0 yet, because other libraries depending on the API definitions don’t support it yet.
• Regarding moving nullable: true to OtherObject. This other object is intended to appear in non-nullable form in other places. I naively thought I can wrap it into OtherObjectNullable, but that again results in having to combine $ref with nullable: true. This maybe leaves duplicating all fields in OtherObject and OtherObjectNullable as an option, which calls for trouble when changing the fields and forgetting to sync them.