This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
[release/3.1] Make sure original Utf8JsonReader options are honored when re-creating the reader. #42867
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ports dotnet/runtime#31791 from 5.0/master
Fixes dotnet/runtime#882
Description
Generate the
JsonReaderOptions
from the the user-defined, passed-inJsonSerializerOptions
, and use that to create theUtf8JsonReader
, rather than the default options. The fix is a couple of lines, with the rest of the PR adding tests and test enhancement.Customer Impact
This bug was initially reported in user-defined
JsonConverter<T>
where the user couldn't deserialize a deeply nested object graph (beyond the default max depth of 64). The issue, however, is not just specific to converters (nor just toMaxDepth
) and will be hit whenever the caller passes in aUtf8JsonReader
to theJsonSerializer.Deserialize
method with non-defaultJsonReaderOptions
set (which currently includesMaxDepth
,JsonCommentHandling
, andAllowTrailingCommas
).For example, this code snippet incorrectly fails with an exception:
It is clear that we should be honoring the user-defined options. Otherwise, there is no way for callers to deserialize payloads containing trailing commas or comments when using the
Utf8JsonReader
with theJsonSerializer
. We should make sure to meet user expectations here (otherwise, even debugging the issue would become difficult for them).There is no reasonable workaround for the user. In fact, the
JsonConverter<T>
extension point is the primary workaround to change default serialization behavior, which increases the need for this fix since that isn't working as expected.Regression
No. The bug existed in the deserialization behavior since the initial release of S.T.Json as part of 3.0.
Testing
Added several permutations within the test including customer reported scenario. The fix for the bug is only a couple of lines and only affects the read/deserialize, but I wanted to make sure we add tests to exercise the various options for both read and write. We already have decent negative test cases (where the default options throw for invalid JSON), but were missing positive test cases (where custom options worked to make the reader more flexible).
The writer tests are only there for completeness and fill a gap from when the
JsonSerializer
APIs that accept a writer were originally added (see #38700 (comment)). Those tests pass in master and 3.1 already with no source changes.Risk
Low given it is a very targeted fix with no regression. This fix only affects the deserialization behavior. One scenario where a customer could be impacted is if they accidentally relied on the default reader options to catch/throw for JSON that might contain comments/trailing commas, even when they were setting the options to be flexible. The fix for that would be to make sure the options match what you expect.
cc @ericstj