Backport Stop Serializing Return Values for InvokeVoidAsync (#35807)

[TanayParikh]

Backport #35807 to 6.0

• Automated backport failed, hence the manual backport.

[TanayParikh]

Auto-merging as this is just a backport (would be self-approved if the automated backport went through).

[TanayParikh]

@dotnet/aspnet-build is there a way to skip these failures (while still running the rest of the code-check)? I'm hesitant to force merge via admin rights as that would likely cause issues in future CI runs.

It's due to this change:
https://github.com/dotnet/aspnetcore/pull/35979/files#diff-0fe63cf448eeb02abbee5f1d260fdbc67c9f41a434812e8be1585c0caaf0b697

Those two API changes have been approved by @Pilchie as well as the API review process to go into RC2.

[dougbu]

@TanayParikh this is a known issue that'll last from now 'til 6.0 RTM. We could special case that part of the Code Check script but then we have yet-another thing to change when preparing for RTM. In addition, the bar for API changes is already higher and going up pretty swiftly.

So, if the only complaint in 'release/6.0' changes is about making API changes, use your admin privileges to merge.

[TanayParikh]

So, if the only complaint in 'release/6.0' changes is about making API changes, use your admin privileges to merge.

Would this potentially cause issues on future CI runs based off of release/6.0 considering this failure would persist? Or would the failure not persist because the "baseline" would include this change?

[dougbu]

Would this potentially cause issues on future CI runs based off of release/6.0 considering this failure would persist?

Not exactly. Any particular API change will cause failures in the change itself but won't affect later builds. The problem will recur (and has occurred) every time a new API change is introduced.

[TanayParikh]

So, if the only complaint in 'release/6.0' changes is about making API changes, use your admin privileges to merge.

Yep, it's the only failure. Merging.