Fix handling of nullable enums for 3.0

[Youssef1313]

Previously, this scenario wasn't producing a type and wasn't producing a null value in the enum array.

This fixes it so that they are produced.

In the future, we could also avoid adding a oneOf with a single element in this scenario.

[DeagleGross]

should this be count > 1 because enum values will have null and at least one enum value? Maybe I am wrong

[Youssef1313]

It's valid (and more correct) to not have null in the enum array. We are dealing with something like:

"oneOf": [
  {
    "type": "null"
  },
  {
    "enum": [
      // ...
    ]
  }
]

The enum array could have a single element, and in all reasonable practical use cases, it must not have null, because then null becomes invalid as it matches both child schemas.

Note that the above shape is draft 2020-12, which isn't what we emit for OpenAPI 3.0. However, the OpenApiSchema model is designed more towards the 2020-12 draft.

That's why we can't emit the thing as-is and we have to do lots of special casing for versions. So, we emit the exact shape above that I mentioned for 3.1 and 3.2 which use 2020-12. But the same OpenApiSchema model serializes differently for 3.0 because it's not really using 2020-12 draft and the above shape isn't valid for OpenAPI 3.0.

That's at least how I'm understanding things currently.

[baywet]

valid yes. More correct, not really. Each keyword is evaluated independently, the instance needs to validate one of the keywords. And enums are effectively oneOf consts. We could argue it's easier to ready though.

[Youssef1313]

@baywet

What I mean is something like:

"oneOf": [
  {
    "type": "null"
  },
  {
    "enum": [
      "A",
      "B",
      null
    ]
  }
]

In this case, null matches both child schemas. And so, oneOf fails and null won't be considered valid.

See https://www.jsonschemavalidator.net/s/bdAKMMTl

So my point is that a schema like the above is pointless.

[baywet]

Thank you for making the changes!

[Youssef1313]

@baywet Is there anything remaining to get this merged? Would we have a new version released before .NET 11 Preview 7 so that we try to get that in aspnetcore repo and possibly build some fixes on our side on top of this?