Passing generic class with nullable reference type in JsonSerializableAttribute raises CS8620 when used

[JenyaRostov]

Description

Take this class

[JsonSerializable(typeof(IDictionary<string, object?>))]
public partial class JsonContextTest : JsonSerializerContext { }

When used like this:

IDictionary<string, object?> d = new Dictionary<string, object?>()
{
 ["A"] = "b",
 ["D"] = 1,
 ["C"] = null
};
var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject);

It raises CS8620 Argument of type 'System.Collections.Generic.IDictionary<string,object?>' cannot be used for parameter 'inputValue' of type 'System.Collections.Generic.IDictionary<string,object>?' in 'System.Net.Http.Json.JsonContent.Create<T>' because of differences in the nullability of reference types
Generated code for JsonContextTest:

public global::System.Text.Json.Serialization.Metadata.JsonTypeInfo<global::System.Collections.Generic.IDictionary<string, object>> IDictionaryStringObject

Notice the absence of object?
It does not raise any runtime errors however when using
My colleague is treating all warnings as errors so is there any way to avoid raising CS8620 besides NoWarn?

Reproduction Steps

Create class

[JsonSerializable(typeof(IDictionary<string, object?>))]
public partial class JsonContextTest : JsonSerializerContext { }

Use it

IDictionary<string, object?> d = new Dictionary<string, object?>()
{
 ["A"] = "b",
 ["D"] = 1,
 ["C"] = null
};
var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject);

Expected behavior

No warning raised

Actual behavior

CS8620 is raised

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Take this class

[JsonSerializable(typeof(IDictionary<string, object?>))]
public partial class JsonContextTest : JsonSerializerContext { }

When used like this:

IDictionary<string, object?> d = new Dictionary<string, object?>()
{
 ["A"] = "b",
 ["D"] = 1,
 ["C"] = null
};
var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject);

It raises CS8620 Argument of type 'System.Collections.Generic.IDictionary<string,object?>' cannot be used for parameter 'inputValue' of type 'System.Collections.Generic.IDictionary<string,object>?' in 'System.Net.Http.Json.JsonContent.Create<T>' because of differences in the nullability of reference types
Generated code for JsonContextTest:

public global::System.Text.Json.Serialization.Metadata.JsonTypeInfo<global::System.Collections.Generic.IDictionary<string, object>> IDictionaryStringObject

Notice the absence of object?
It does not raise any runtime errors however when using
My colleague is treating all warnings as errors so is there any way to avoid raising CS8620 besides NoWarn?

Reproduction Steps

Create class

[JsonSerializable(typeof(IDictionary<string, object?>))]
public partial class JsonContextTest : JsonSerializerContext { }

Use it

IDictionary<string, object?> d = new Dictionary<string, object?>()
{
 ["A"] = "b",
 ["D"] = 1,
 ["C"] = null
};
var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject);

Expected behavior

No warning raised

Actual behavior

CS8620 is raised

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8

Other information

No response

Author:	JenyaRostov
Assignees:	-
Labels:	area-System.Text.Json
Milestone:	-

[eiriktsarpalis]

This is by design -- the STJ source generator is nullable reference type agnostic but it still supports NRTs. You can safely suppress the warning at the callsite like so:

var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject!);

[JenyaRostov]

This is by design -- the STJ source generator is nullable reference type agnostic but it still supports NRTs. You can safely suppress the warning at the callsite like so:

var b = JsonContent.Create(d, JsonContextTest.Default.IDictionaryStringObject!);

It works when adding ! to d and not IDictionaryStringObject
Still, is there a way to not raise the warning at all?

[eiriktsarpalis]

Other than suppressing nullability warnings locally, not really.

FWIW The source generator will intentionally discard any nullability annotations you might be putting on JsonSerializableAttribute. This is because the underlying metadata model being generated is being keyed on System.Type which cannot distinguish between object? and object.

In the future we should investigate having the source generator emitting nullable-oblivious JsonTypeInfo properties.

[RenderMichael]

FWIW The source generator will intentionally discard any nullability annotations you might be putting on JsonSerializableAttribute. This is because the underlying metadata model being generated is being keyed on System.Type which cannot distinguish between object? and object.

This issue has led to usability problems for me, especially when working with people who are loath to suppress any nulls, especially when using an API idiomatically like this.

This justification is an implementation detail, and luckily doesn’t prevent NRTs from being used.

Would it be possible to just blindly pass along the same NRTs that were supplied?

[eiriktsarpalis]

This justification is an implementation detail, and luckily doesn’t prevent NRTs from being used.

I wouldn't consider it an implementation detail, it is an essential consequence of the architecture that JsonSerializer is using (i.e. contract metadata being keyed on System.Type which is NRT-agnostic). This is unlikely to ever change in the future, although as mentioned the generated properties could be made null-oblivious since they work for all possible annotations.

especially when working with people who are loath to suppress any nulls, especially when using an API idiomatically like this.

It's odd that people would think this. NRT annotations are a very useful tool but cannot provide a complete representation of the actual run-time nullability semantics. Null suppressions are occasionally necessary, we often use them in dotnet/runtime production code.