[release/6.0] Stop enforcing JSON read till end if EndInvokeJS returns early

[TanayParikh]

Stop enforcing JSON read till end if EndInvokeJS returns early

Description

We don't want to enforce we've read till the end of the JSON if we've just abandoned the EndInvokeJS call entirely due to the task timing out or getting cancelled. If we abandoned the EndInvokeJS call, we know we haven't read till the end of the JSON payload (and that's expected), hence we shouldn't be throwing a JSON exception in that case.

Fixes #39087, #38962, #34267
Backports #39060

Customer Impact

If the user calls for OpenReadStream, but before processing the stream request, .NET cancels, then the JSON exception is thrown, fatally crashing the circuit & application. End user must reload the page to continue. This scenario can be triggered via the following sample code.

<InputFile OnChange="@OnInputFileChange" />

@code {
    private void OnInputFileChange(InputFileChangeEventArgs e)
    {
        using var content = new MultipartFormDataContent();

        var fileContent = new StreamContent(e.File.OpenReadStream());

        // await Task.Delay(10_000); // Uncomment to stop exception (as we no longer cancel before the response is interpreted)
        Console.WriteLine("Hi I'm here without fail");
    }
    // We finish execution of the function immediately after calling `OpenReadStream`.
    // The GC thus disposes locals, thereby immediately cancelling the `OpenReadStream` request.
    // Within the framework, this translates to the `EndInvokeJS` request being cancelled for `OpenReadStream`
    // before the initial payload of the request can be processed. This is okay, and we shouldn't be enforcing
    // that the entire request was read. This is what this PR fixes. 
}

Exception details

Regression?

• Yes
• No

This is a regression from .NET 5. In .NET 6 we completely overhauled the underlying streaming mechanism which resulted in this edge case regression.

Risk

• High
• Medium
• Low

We're no longer throwing an exception that the payload is unread in the event that a JSInterop call is called. When a JSInterop call is cancelled, we don't expect the payload to be read, so an exception is unnecessary.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @TanayParikh. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[mkArtakMSFT]

This won't meet the bar for a patch.

[GerkinDev]

Might I expect it to land on the next patch along with other fixes though ?

[ghost]

Hi @GerkinDev. 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.

[TanayParikh]

Might I expect it to land on the next patch along with other fixes though ?

At this point we are not planning on patching this for 6.0 due to limited user reports and the fact that this isn't a regression for .NET 5. We'll keep monitoring the issue and reassess should this start impacting a larger number of users.

[ghost]

Hi @TanayParikh. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[TanayParikh]

Bringing this in for 6.0 patch consideration given the regressing behavior reported in #39087.

[TanayParikh]

@dotnet/aspnet-build can this please be merged.