Response is always nullable under generateNullableReferenceTypes?

[jods4]

Given this basic OpenApi:

"get": {
  "responses": {
    "200": {
      "content": {
        "application/json": {
          "schema": {
            "$ref": "#/components/schemas/response"
          }

And when option generateNullableReferenceTypes is true, then the following method is generated:

[Get("/")]
Task<Response?> Get();

Why is Response nullable? Is my OpenApi missing a property to indicate the response is always present?
When the API is successful (200) there is a Response object.

With this code generation I basically have to always bang ! my Refit responses.

[christianhelle]

@jods4 thanks for bringing this up. The option generateNullableReferenceTypes is an NSwag specific option, and I just 100% piggy-back over NSwag for parsing the OpenAPI document. It seems that setting generateNullableReferenceTypes always generates null reference types. But in the case of the generated Refit interface, I tend to use the Task<IApiResponse<T>> return type to avoid exceptions for failed responses

All that said, since Refitter generates the Refit interface, if a get method will never return null and instead throw an exception, then we can ignore the fact the NSwag says it returns a nullable type, and just declare the Refit interface method to return a non-nullable type.

I'll play around with this a bit and see if we can find a good solution

[jods4]

Hi @christianhelle,
Did you find something to make the return type in interface non-nullable on your side?
Do you think I should open an issue on NSwag instead (I'd like to be sure that it's 100% on NSwag side, as I'm not using it directly)?

[christianhelle]

@jods4 I unfortunately completely forgot about this issue.

NSwag just released a recent major version update that might include what you need. I'll try to revisit this tonight after I put the family to bed

[jods4]

@christianhelle I tried with latest Refitter -- which I believe uses NSwag 14? -- and nothing changed.

[christianhelle]

@jods4 I looked into this a bit last night and can see that NSwag itself generates its interface as

        /// <summary>Find pet by ID</summary>
        /// <param name="petId">ID of pet to return</param>
        /// <returns>successful operation</returns>
        /// <exception cref="ApiException">A server side error occurred.</exception>
        System.Threading.Tasks.Task<Pet> GetPetByIdAsync(long petId);

So I looked into the code a bit and found

When I set the isNullable argument to false then the Refit interface is generated as

        /// <summary>Find pet by ID</summary>
        /// <remarks>Returns a single pet</remarks>
        /// <param name="petId">ID of pet to return</param>
        /// <returns>successful operation</returns>
        /// <throws cref="ApiException">Thrown when the request returns a non-success status code.</throws>
        [Headers("Accept: application/json")]
        [Get("/pet/{petId}")]
        Task<Pet> GetPetById(long petId);

even though I set generateNullableReferenceTypes to true in the refitter settings

This looks like a bug in Refitter that is trivial to fix. My little concern here is that Refitter users have most likely just worked around this issue and introducing this "fix" would "break" things for others

[jods4]

I understand your concerns; we had to "fix" this ourselves as well.
I don't see many ways to work around the current codegen: we either use ?. or ! when accessing the response (I guess you could also check x == null).

So I just verified this on SharpLab: none of those patterns warn when the type is changed to a non-nullable reference.

I guess the risk of breaking things is low?

Long term I think this is something worth fixing because when working with nullable reference the current behavior is just annoying and objectively wrong. If you want zero risk you could provide a setting to configure the codegen but that's maintenance burden for you.

[christianhelle]

@jods4 I agree that this should be fixed, it will cause a minor inconvenience to those who have implemented a work-around. You are right that in the long term its better to fix it

I created issue #302 and I will fix this today

[jods4]

Awesome, thanks a lot!

[christianhelle]

@jods4 You're welcome. Thanks for bringing this up again. The traction and positive that I received for Refitter can be a bit overwhelming and it's a bit hard to follow every single thing. I completely forgot to follow up on this one so I'm sorry for the delay and inconvenience

I will release the fix once this pull request gets merged in

[jods4]

No worries! I actually had forgotten about this as well but stumbled upon it again when writing new code.

Refit is a great way to manually write API clients, and Refitter is a super helpful companion tool when OpenAPI definitions are available. Thanks! ❤

[christianhelle]

The fix for this is released in version 0.9.6