Remove JsonSerializerOptions copy in ProblemDetailsJsonOptionsSetup

[brunolins16]

Fixes #46143

Waiting for #46303

[davidfowl]

Why are we checking for null?

[brunolins16]

I don't think make sense we setup our internal context when the app is configured for reflection-based, and actually this condition might be something like options.SerializerOptions.TypeInfoResolver is not null && if (options.SerializerOptions.TypeInfoResolver is not DefaultTypeInfoResolver or options.SerializerOptions.TypeInfoResolver is JsonSerializerContext

[davidfowl]

Why?

[brunolins16]

I feel like it is useless, I believe our context will never be used in this case since it will be added later or even worse, if it was null, now the app might break because we set a context. The only scenario where adding it helps it if, when null, another post-config sets a context.

[davidfowl]

Why does the app break if we set a context?

[davidfowl]

The summary is, once you add a context, the reflection based one will not be used ever?

cc @eiriktsarpalis

[davidfowl]

This breaks right:

var options = new JsonSerializerOptions();
options.AddContext<MyContext>();
JsonSerializer.Serialize(new Student("David", 1), options);

record Student(string Name, int Grade);
record Person(string Name);

[JsonSerializable(typeof(Person))]
partial class MyContext : JsonSerializerContext
{

}

[eiriktsarpalis]

The summary is, once you add a context, the reflection based one will not be used ever?

Correct. If the TypeInfoResolver property has been configured, then the serializer will not attempt to populate it with reflection resolution.

[brunolins16]

The summary is, once you add a context, the reflection based one will not be used ever?

The only scenario it will not be true is if you set the DefaultTypeInfoResolver first, but in this case your source gen context will not be used. This will work:

var options = new JsonSerializerOptions() { TypeInfoResolver = new DefaultJsonTypeInfoResolver() };
options.AddContext<MyContext>();
JsonSerializer.Serialize(new Student("David", 1), options);

record Student(string Name, int Grade);
record Person(string Name);

[JsonSerializable(typeof(Person))]
partial class MyContext : JsonSerializerContext
{}

[brunolins16]

Just be make it clear, the call to AddContext append the new context to be executed later.

https://github.com/dotnet/runtime/blame/2b8514b02f6d0e87f4645aca0be38f16864004a7/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonSerializerOptions.cs#L179

Since the reflection-based will be able to GetTypeInfo we will never call the source generated context

https://github.com/dotnet/runtime/blob/2b8514b02f6d0e87f4645aca0be38f16864004a7/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonTypeInfoResolver.cs#L69-L74

[davidfowl]

This isn't making sense to me. Why don't we always want to use this context? Also changes like this that aren't obvious need to big comment 😄

[brunolins16]

I can add a 😂 "huge" comment when we decided what is the right thing to do. As I mentioned && options.SerializerOptions.TypeInfoResolver is not DefaultJsonTypeInfoResolver can be easily removed, however, it will be useless, unless we change how the AddContext works (to prepend instead of append).

[brunolins16]

unless we change how the AddContext works (to prepend instead of append)

After a conversation with @eiriktsarpalis, changing it doesn't make sense. As an example:

options.AddContext<Foo>();
options.AddContext<Bar>();
options.AddContext<Baz>();

Should be equivalent to writing:

options.TypeInfoResolver = JsonTypeInfoResolver.Combine(Foo.Default, Bar.Default, Baz.Default);

[davidfowl]

The problem seems like the JSON fallback needs to be applied BEFORE the first class to AddContext to make everything work in all cases. Is that right? We don't want to override the reflection resolver if it'll eventually be newed up lazily by the the JSON library.

[brunolins16]

JSON fallback needs to be applied BEFORE the first class to AddContext to make

After. but everything else is correct. I believe we should keep the options.SerializerOptions.TypeInfoResolver is not null to avoid breaking an app due to our internal context but I am less concerned about options.SerializerOptions.TypeInfoResolver is not DefaultJsonTypeInfoResolver since it will not make any difference, what do you think?

[eiriktsarpalis]

I tend to agree with David that the source generated context could go first even in cases where you have reflection enabled. It would save you a relatively small amount of initialization costs, particularly around JITing all the dynamic methods that ProblemDetails requires. But maybe not a huge win if everything else is dynamically generated.

You wouldn't need to change the semantics of AddContext to achieve that though, you could simply use the Combine method to prepend whatever resolver you like to user configuration.

[brunolins16]

Closing this PR in favor of #46303.

[ghost]

Hi @brunolins16. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.