Skip to content

Revert back to JsonElement-backed JsonValue for deserialization #116774

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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 Copilot AI review requested due to automatic review settings June 18, 2025 01:22
Copy link
Contributor

@Copilot 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

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.

@@ -624,7 +679,14 @@ public static IEnumerable<object[]> GetPrimitiveTypes()
yield return Wrap(new DateOnly(2024, 06, 20), JsonValueKind.String);
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants