[ci-fix] Needs review: Unwrap TargetInvocationException in AsyncEnumerable tests on tvOS Mono (refs #128766)

[github-actions]

Workflow artifact: ci-fix
Artifact kind: help
Linked KBE: #128766

Note

This is an AI/Copilot-generated draft PR that attempts to fix the CI failure described in KBE #128766. It has NOT been build-validated (environment lacks .NET 11 SDK). Human review is needed.

Root cause

On tvOS Mono, exceptions thrown during async iterator execution in JsonSerializer.SerializeAsyncEnumerable are wrapped in a System.Reflection.TargetInvocationException. The tests use Assert.ThrowsAsync<InvalidOperationException> which fails when the expected exception is wrapped.

Failing log line:

Expected: typeof(System.InvalidOperationException)
Actual:   typeof(System.Reflection.TargetInvocationException)

This is a known behavioral difference in Mono's async iterator exception propagation. The InvalidOperationException IS correctly thrown by the serializer, but Mono wraps it during the async pipeline unwinding.

Fix

Replace Assert.ThrowsAsync<InvalidOperationException> with:

Exception ex = await Assert.ThrowsAnyAsync<Exception>(...);
if (ex is TargetInvocationException { InnerException: { } inner })
    ex = inner;
Assert.IsType<InvalidOperationException>(ex);

This correctly handles both:

• CoreCLR: gets InvalidOperationException directly — assertion passes
• Mono/tvOS: gets TargetInvocationException wrapping InvalidOperationException — unwraps and passes

Remove the [ActiveIssue] annotations since the fix addresses the root cause.

What is unverified / help needed

• Build not validated: Environment has .NET 8/9 SDKs; the project targets .NET 11 preview.
• Mono runtime bug: The real fix should be in Mono's async iterator exception propagation. This test change is a workaround that accepts Mono's behavior. Is that acceptable, or should the Mono runtime be fixed instead?
• Other tests: There may be other tests in System.Text.Json that assert specific exception types from async operations and could have the same issue on Mono.

Suggested reviewers / area contacts

• @eiriktsarpalis (area-System.Text.Json owner)
• @simonrozsival (Apple mobile / Mono contributor)

Validation

• Command: dotnet build src/libraries/System.Text.Json/tests/System.Text.Json.Tests/System.Text.Json.Tests.csproj
• Result: not run because environment lacks .NET 11 SDK

Evidence

• Failing build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1438268
• First build it occurred: 2026-05-25T09:02:27Z (persistent across entire scanned window; true origin may predate 2026-05-24)
• Suspected regressing change: none identified; likely a Mono behavioral difference exposed when this test started running on tvOS

---

Filed by ci-failure-fix, which attempts validated fixes for [ci-scan] Known Build Errors and otherwise loops in owners. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• [ci-scan] Test failure: CustomAttributeDecoderTests.TestCustomAttributeDecoderGenericUsingReflection on maccatalyst #128450 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [ci-scan] Test failure: CryptoStreamTests.ReadWrite_Success MemberData not found on maccatalyst #128451 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Fixer · ● 60.4M · ◷

[dotnet-policy-service]

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