Skip to content

Conversation

@PranavSenthilnathan
Copy link
Member

JsonValueOfElement is more permissive than other classes derived from JsonValue. For example, it allows GetValue<Guid> even when the underlying value's JSON type is a JSON string. The following method has the implementation:

public override bool TryGetValue<TypeToConvert>([NotNullWhen(true)] out TypeToConvert value)

#115856 changed deserialization of primitives to use JsonValue.Create instead of the JsonElement-backed creation, so the people relying on the previous behavior of GetValue will now be broken. This was a small part of that PR and only that part has been reverted in this PR.

In the long term, we can reintroduce this change in a different way: have another class derived from JsonValue that (1) stores the value instead of JsonElement and (2) also allows the same conversions that JsonValueOfElement does. But for now, we revert to get back to baseline.

Fixes #116730

/cc @eiriktsarpalis @jeffhandley I'm planning to cherry pick this to the release branch as well after merging in main.

@PranavSenthilnathan PranavSenthilnathan added this to the 10.0.0 milestone Jun 18, 2025
@PranavSenthilnathan PranavSenthilnathan self-assigned this Jun 18, 2025
Copilot AI review requested due to automatic review settings June 18, 2025 01:22
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR reverts a recent change to primitive deserialization in JsonValue that broke the permissiveness of JsonValueOfElement when using GetValue. It restores behavior by reverting to the JsonElement-backed creation and updates the associated test harness to accommodate the change.

  • Revert deserialization of primitives to use JsonElement-backed JsonValue
  • Update tests to wrap primitive values using a new WrappedT helper type
  • Adjust JsonValueConverter to revert to the previous parsing logic

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
src/libraries/System.Text.Json/tests/System.Text.Json.Tests/JsonNode/JsonValueTests.cs Updated test signatures to use WrappedT and modified the Wrap helper to wrap values in WrappedT
src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Converters/Node/JsonValueConverter.cs Reverted the primitive value deserialization to use JsonElement-backed JsonValue

@dotnet-policy-service
Copy link
Contributor

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

yield return Wrap(new TimeOnly(10, 29), JsonValueKind.String);
#endif
static object[] Wrap<T>(T value, JsonValueKind expectedKind) => [value, expectedKind];
static object[] Wrap<T>(T value, JsonValueKind expectedKind) => [new WrappedT<T> { Value = value }, expectedKind];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

XUnit was coercing T? to T for some types (like char? to char) so the tests weren't actually running for those cases. It doesn't do that when using the custom type.

@eiriktsarpalis
Copy link
Member

In the long term, we can reintroduce this change in a different way: have another class derived from JsonValue that (1) stores the value instead of JsonElement and (2) also allows the same conversions that JsonValueOfElement does. But for now, we revert to get back to baseline.

Any reason why we cannot do this right away? We're not backporting this fix so I think we can afford to do this in a way that both addresses the regression and makes TryGetValue behave consistently regardless of underlying implementation.

@jeffhandley
Copy link
Member

If we can get the "long term" fix into Preview 7, I'm supportive of taking that fix instead of this one, and still having the regression in Preview 6.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 19, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

3 participants