[Bug]: Behaviour change in 8.1.2 for nullable enums

[jadu-1337]

Describe the bug

After updating from 8.1.1 to 8.1.2, there is an issue with type names for nullable enums.

It appears that all enums that are used as nullable values, e.g. class Request { MyEnum? Value { get; set; } } have their schema name changed in the generated resulting OpenAPI spec from MyEnum to MyEnumNullable.

This breaks client code generation that relies on the type names to match C# source, e.g. when using NSwagGen with GenerateDtoTypes:false, the generated client code fails to compile because it references a non-existing MyEnumNullable.

Expected behavior

Schema names should match C# source names

Actual behavior

Schema names are altered.

Steps to reproduce

No response

Exception(s) (if any)

No response

Swashbuckle.AspNetCore version

8.1.2

.NET Version

9.0.5

Anything else?

No response

[martincostello]

This appears to be caused by the changes in #3377.

/cc @ItsVeryWindy

[ItsVeryWindy]

So I've played around with a few different generators, I tried nswag, open api generator and swagger code gen for generating c# code.

In general support seems to vary with what structure works best, with most providing mixed results.

I tried two different approaches whilst still trying to keep the same intent, one which involves using oneOf

"schema": {
              "oneOf": [
                {
                  "$ref": "#/components/schemas/LogLevel"
                },
                {
                  "enum": [
                    null
                  ]
                }
              ],

and another which was suggested in the open api faqs (LogLevel in this instance would include null by default).

"schema": {
              "allOf": [
                {
                  "$ref": "#/components/schemas/LogLevel"
                },
                {
                  "not" : {
                    "enum": [
                      null
                    ]
                  }
                }
              ],

At least for nswag, it was able to generate the expected result when using oneOf, open api generator tried to use the options pattern which I guess is usable but not the best, and swagger code gen came out with garbage.

Using "not" approach in all cases generated either subpar or unusable code.

There are many generators out there, and it's very time consuming to test each an every one. But I wouldn't be surprised if most of them would suck at dealing with this.

I'd maybe suggest going with the first option and adding a flag to allow it to be turned on/off just to allow it to play nicer with code generators.

[martincostello]

Thanks for looking into this.

I'd maybe suggest going with the first option and adding a flag to allow it to be turned on/off just to allow it to play nicer with code generators.

I think this is probably the best option and we make it opt-in.

It's worth bearing in mind that large changes are coming as part of #3283 for OpenAPI 3.1 support, so it may be the case that the change introduced here, while unintended, might become the actual behaviour in a future release. That will however be a major version bump though when it ships. It all depends on how we have to adapt to deal with the changes in Microsoft.OpenApi 2.0.0 - I've see the Nullable part of the naming seep into the generated schemas generated by Microsoft.AspNetCore.OpenApi 9+ as well.

[sam-piper-lendus]

This update has affected our codebase in the same manner, and has broken our frontend build layer which relies on the type names in the Swagger file remaining constant, so that generated TypeScript remains compatible with references in static application code.

We use Axios for OpenAPI code generation from a Swagger.json file.

Is there a way to opt out of this behaviour in 8.1.2 config options? Or should we just wait until this is opt-in on a future version?

[shan32423]

Hi, is there any plan to fix this issue, It also affecting custom SchemaIds. e.g this customization is adding only Nullable in schemas and ids and not allowing to create more than two enums in the same document.

c.CustomSchemaIds(obj=> {
           return obj.Name == nameof(TestObject) ? "TestObject" : obj.Name;
          });

[martincostello]

See #3425 (comment) for thoughts on a path forward.

A fix won't be for at least a week due to personal commitments, so if this issue is causing you problems then just keep using 8.1.1.

[mrange]

Hi. Thanks for looking into it. I understand that this might be the new behaviour in the future but then it should, as you said, it should be a new major version number.

Thanks again.

[glittle]

Same issues. Will stay with 8.1.1. This is a breaking change, so should be 8.2 or 9.0!

[martincostello]

It wasn't a major version bump because it was an unintentional change in behaviour as already stated.

[oyzar]

Any ETA on when this will be fixed?