[BUG][C#] Model properties are generated as non-nullable after 4.1.0 release

[douggish]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

In version 4.0.3, when using an OpenAPI 2.0 input, model properties were generated as nullable. For example, see that the date-time property in the FormatTest class was generated as a DateTime? type in 4.0.3:
https://github.com/OpenAPITools/openapi-generator/blob/v4.0.3/samples/client/petstore/csharp/OpenAPIClient/src/Org.OpenAPITools/Model/FormatTest.cs#L172

But in 4.1.0, the same property is generated as a non-nullable DateTime type:
https://github.com/OpenAPITools/openapi-generator/blob/v4.1.0/samples/client/petstore/csharp/OpenAPIClient/src/Org.OpenAPITools/Model/FormatTest.cs#L172

This is a problem because if a service returns null for these properties in a response, the JSON deserialization fails.

Is there a way to generate nullable properties using an OpenAPI 2.0 input?

openapi-generator version

4.1.0

OpenAPI declaration file content or url

https://github.com/OpenAPITools/openapi-generator/blob/v4.1.0/modules/openapi-generator/src/test/resources/2_0/petstore-with-fake-endpoints-models-for-testing.yaml#L1301

Command line used for generation

See https://github.com/OpenAPITools/openapi-generator/blob/v4.1.0/bin/csharp-petstore-netcore-project.sh#L30

Steps to reproduce

Look at the generated samples in Github for version 4.0.3 and 4.1.0 and compare the types of the properties in the generated models.

Related issues/PRs

I believe this may have been introduced by these pull requests:
#3530
#3537

Suggest a fix

I think the changes made in the above pull requests should only affect OpenAPI 3.0 generation.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[douggish]

Note that this seems to be an issue for both the csharp and csharp-netcore generators

[wing328]

Is there a way to generate nullable properties using an OpenAPI 2.0 input?

@414004738 please try x-nullable: true in OAS 2.0

[douggish]

Hi @wing328. Thanks for the response.

Manually adding x-nullable: true did seem to work. However, we are using swashbuckle to generate the OAS 2.0 JSON files for our C# .net core services and springfox to do the same for our spring boot java services, which don't seem to include the x-nullable: true property in the generated JSON. Do we have to customize the output of these libraries somehow to continue using the latest version of openapi-generator?

[wing328]

PM me via Slack when you've time.

[kevinoid]

Shouldn't the property also be Nullable<T> if it is not required? For example:

DateRange:
  type: object
  properties:
    start:
      type: string
      format: date-time
    end:
      type: string
      format: date-time
  required:
  - start

If the generated End property is DateTime instead of DateTime? and an open-ended range is represented by omitting the end property (rather than sending/receiving null), how would the client represent that?

[kevinoid]

For reference, Autorest uses Nullable<T> for properties which are either not required or x-nullable: true, whereas openapi-generator appears to only consider x-nullable.

[rizwansaeed]

Is the change in behaviour a feature or bug? We're planning to move to the csharp-netcore implementation but this is currently blocking us. Will adding x-nullable: true be required going forward in order to get the behaviour from 4.0.3?

Thanks

[wing328]

@rizwansaeed nullable property will determine the behavior moving forward.

The previous implementation was based on OAS v2, which does not support nullable (later it's supported via x-nullable)

[kevinoid]

@wing328 Are you saying required should have no effect in OAS3?