Use native NullabilityInfoContext #1167

maurei · 2022-07-05T23:19:09Z

Use the native NullabilityInfoContext for checking on nullability information rather than relying on Swashbuckles work-around.

codecov · 2022-07-06T02:02:26Z

Codecov Report

Merging #1167 (0cc59db) into openapi (f65b7fe) will increase coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head 0cc59db differs from pull request most recent head 49f9ff2. Consider uploading reports for the commit 49f9ff2 to get more accurate results

@@             Coverage Diff             @@
##           openapi    #1167      +/-   ##
===========================================
+ Coverage    92.24%   92.27%   +0.03%     
===========================================
  Files          302      301       -1     
  Lines         8768     8756      -12     
===========================================
- Hits          8088     8080       -8     
+ Misses         680      676       -4

Impacted Files	Coverage Δ
...ApiDotNetCore.OpenApi/JsonApiObjects/SingleData.cs	`0.00% <ø> (ø)`
...etCore.OpenApi/ResourceFieldAttributeExtensions.cs	`100.00% <100.00%> (+12.50%)`	⬆️
...penApi/SwaggerComponents/JsonApiSchemaGenerator.cs	`98.36% <100.00%> (+0.02%)`	⬆️
...ggerComponents/ResourceFieldObjectSchemaBuilder.cs	`98.97% <100.00%> (+1.02%)`	⬆️
...NetCore/Repositories/ResourceRepositoryAccessor.cs	`100.00% <100.00%> (ø)`

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

bkoelman

I'm in favor of relying on NullabilityInfoContext eventually, but I think tests should be part of this PR to ensure correctness today.

Resolving the nullability state turns out to be quite complicated when generics are involved. And I found that .NET 6 contains quite some bugs, which were recently fixed for .NET 7.

For example, simple cases like the following fail to produce the correct result on .NET 6:

#nullable enable
class Customer : Identifiable<string>
{
}

PropertyInfo property = typeof(Customer).GetProperty("Id")!;
NullabilityInfoContext nullContext = new NullabilityInfoContext();
NullabilityInfo nullability = nullContext.Create(property);
Console.WriteLine(nullability.ReadState); // prints Nullable

bkoelman · 2022-07-09T11:40:35Z

src/JsonApiDotNetCore.OpenApi/ResourceFieldAttributeExtensions.cs

-        };
+        NullabilityInfo nullabilityInfo = NullabilityInfoContext.Create(source.Property);
+
+        return nullabilityInfo.ReadState == NullabilityState.Nullable && !hasRequiredAttribute;


I think the first part should be nullabilityInfo.ReadState != NullabilityState.NotNull, to account for Unknown (NRT off)

Unlike JsonApiSchemaGenerator.IsDataPropertyNullable, here properties can indeed live in types that have NRT disabled, so this is a bug. This slipped through because at this point there aren't any tests that check the behaviour for NRT disabled input. I have a PR lined up for #1111 where these scenarios are extensively tested

I agree that it would be better to have these test cases worked out extensively before changing this mechanism. I will put this PR on hold for now.

bkoelman · 2022-07-09T11:43:45Z

src/JsonApiDotNetCore.OpenApi/SwaggerComponents/JsonApiSchemaGenerator.cs

-
-        return typeCategory == TypeCategory.NullableReferenceType;
+        NullabilityInfo nullabilityInfo = NullabilityInfoContext.Create(dataProperty);
+        return nullabilityInfo.ReadState == NullabilityState.Nullable;


Should probably be:

return nullabilityInfo.ReadState != NullabilityState.NotNull;

to handle the case where the state is Unknown (NRT off). Although I wonder if that situation can occur, assuming the Data property is defined inside JADNC.

Although I wonder if that situation can occur, assuming the Data property is defined inside JADNC.

Correct! The nullability info of property it checks are within types that are internal to JADNC, where NRT is guaranteed to be enabled.

Upon looking at it again, however, I realised there is an even easier check we can perform. This resulted in removing this block code entirely.

bkoelman · 2022-07-09T11:50:43Z

src/JsonApiDotNetCore.OpenApi/SwaggerComponents/ResourceFieldObjectSchemaBuilder.cs

@@ -224,6 +225,7 @@ private static bool IsDataPropertyNullable(Type type)
            throw new UnreachableCodeException();
        }

-        return dataProperty.GetTypeCategory() == TypeCategory.NullableReferenceType;
+        NullabilityInfo nullabilityInfo = NullabilityInfoContext.Create(dataProperty);
+        return nullabilityInfo.ReadState == NullabilityState.Nullable;


Same remark as for JsonApiSchemaGenerator.IsDataPropertyNullable applies here.

Same answer applies as for JsonApiSchemaGenerator.IsDataPropertyNullable. The argument type is always a relationship schema type managed by JADNC.

bkoelman · 2022-07-09T11:51:25Z

src/JsonApiDotNetCore.OpenApi/JsonApiObjects/SingleData.cs

-    where TData : ResourceIdentifierObject
+    // ReSharper disable once RedundantNotNullConstraint
+    // See ReSharper bug: https://youtrack.jetbrains.com/issue/RSRP-489137/False-positive-on-RedundantNotNullConstraint
+    where TData : notnull, ResourceIdentifierObject


I'm not seeing any tests fail when removing the notnull constraint. Why is it needed here?

Initially I had an implementation for JsonApiSchemaGenerator.IsDataPropertyNullable that did depend on this constraint being there. I did something similar to the bug report I did for ReSharper. However now these helper methods behave in an entirely different way, so no longer tests will fail.

Nevertheless, for completeness I figured it would be good to keep the constraints.

However, looking closely at this bug report, I wonder if this is really a bug report in ReSharper, or if ReSharper is actually right and it is a bug in net60.

…iTestContext to allow for this

maurei changed the base branch from master to openapi July 5, 2022 23:19

maurei requested a review from bkoelman July 5, 2022 23:22

maurei marked this pull request as ready for review July 5, 2022 23:41

bkoelman requested changes Jul 9, 2022

View reviewed changes

bkoelman marked this pull request as draft August 21, 2022 15:02

maurei added 3 commits September 6, 2022 13:14

Added tests for nullable and required properties in schema generation

99dcfa8

Added handling of modelstate validation in setting required attributes

2604f84

Not all swagger documents need to be saved to disk; changes in OpenAp…

f7194d9

…iTestContext to allow for this

maurei force-pushed the openapi-nullability-context branch from 0cc59db to 7143a7d Compare September 6, 2022 15:16

maurei added 2 commits September 6, 2022 17:32

Added OpenApi client tests for nullable and required properties

858aa6e

Use NullabilityInfoContext for nullability information

49f9ff2

maurei force-pushed the openapi-nullability-context branch from 7143a7d to 49f9ff2 Compare September 6, 2022 15:34

maurei closed this Sep 6, 2022

maurei deleted the openapi-nullability-context branch September 6, 2022 15:37

maurei mentioned this pull request Sep 6, 2022

Support NRT and MSV in required and nullable #1185

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Use native NullabilityInfoContext #1167

Use native NullabilityInfoContext #1167

Uh oh!

maurei commented Jul 5, 2022 •

edited

Loading

Uh oh!

codecov bot commented Jul 6, 2022 •

edited

Loading

Uh oh!

bkoelman left a comment

Uh oh!

bkoelman Jul 9, 2022

Uh oh!

maurei Jul 9, 2022

Uh oh!

bkoelman Jul 9, 2022

Uh oh!

maurei Jul 9, 2022 •

edited

Loading

Uh oh!

bkoelman Jul 9, 2022

Uh oh!

maurei Jul 9, 2022

Uh oh!

bkoelman Jul 9, 2022

Uh oh!

maurei Jul 9, 2022

Uh oh!

Uh oh!

Uh oh!

Use native NullabilityInfoContext #1167

Use native NullabilityInfoContext #1167

Uh oh!

Conversation

maurei commented Jul 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Jul 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

bkoelman left a comment

Choose a reason for hiding this comment

Uh oh!

bkoelman Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

maurei Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

bkoelman Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

maurei Jul 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkoelman Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

maurei Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

bkoelman Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

maurei Jul 9, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

maurei commented Jul 5, 2022 •

edited

Loading

codecov bot commented Jul 6, 2022 •

edited

Loading

maurei Jul 9, 2022 •

edited

Loading