fix(csharp): always clone request before send to prevent ObjectDisposedException on retry

[patrickthornton]

Closes FER-11195

Summary

• Basis-Theory hit ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.Http.StringContent' from RawClient.CloneRequestAsync on the first retry of a JSON request.
• Root cause: SendWithRetriesAsync sent the original HttpRequestMessage for the initial attempt and only cloned for subsequent retries. Under HTTP/2 (and some other configurations), HttpClient disposes the Content of every request it sends, so the original's Content was already disposed by the time the retry loop tried to clone it.
• Fix: restructure the retryable-content branch to always send a clone — never the original. Cloning each attempt keeps the original Content alive across the entire retry loop.
• Plus four review-driven additions: clamp negative MaxRetries to 0; short-circuit MaxRetries == 0 and non-retryable content to a no-clone fast path; thread CancellationToken into CloneRequestAsync's body buffering; new multi-retry regression test using a DelegatingHandler that disposes request.Content after send.

Customer stack trace

System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Http.StringContent'.
   at System.Net.Http.HttpContent.CheckDisposed()
   at System.Net.Http.HttpContent.CopyToAsync(Stream stream, TransportContext context)
   at BasisTheory.Client.Core.RawClient.<CloneRequestAsync>d__12.MoveNext()
   at BasisTheory.Client.Core.RawClient.<SendWithRetriesAsync>d__13.MoveNext()
   at BasisTheory.Client.Core.RawClient.<SendRequestAsync>d__10.MoveNext()
   at BasisTheory.Client.ReactorsClient.<ReactAsyncCore>d__10.MoveNext()

Before vs after

Before — original sent on attempt 0, cloned only for retries; first send disposed the original's Content:

var response = await httpClient.SendAsync(request, ...);   // (A) ORIGINAL — HTTP/2 disposes its Content
// ...
for (var i = 0; i < maxRetries; i++) {
    if (!ShouldRetry(response)) break;
    using var retryRequest = await CloneRequestAsync(request);   // (B) original.Content already disposed → throws
    response = await httpClient.SendAsync(retryRequest, ...);
}

After — fast path for opt-out cases; always-clone loop for retryable content:

var maxRetries = Math.Max(0, options?.MaxRetries ?? Options.MaxRetries);
var isRetryableContent = IsRetryableContent(request);

if (!isRetryableContent || maxRetries == 0) {
    // Fast path: send the original directly, no clone.
    var response = await httpClient.SendAsync(request, ...);
    return new ApiResponse { ... };
}

// Always send a clone — never the original.
HttpResponseMessage? response = null;
for (var attempt = 0; attempt <= maxRetries; attempt++) {
    if (attempt > 0) {
        var delayMs = GetRetryDelayFromHeaders(response!, attempt - 1);
        await SystemTask.Delay(delayMs, cancellationToken);
    }
    using var attemptRequest = await CloneRequestAsync(request, cancellationToken);
    response = await httpClient.SendAsync(attemptRequest, ...);
    if (!ShouldRetry(response)) break;
}

Why our existing test missed it

SendRequestAsync_ShouldPreserveJsonBody_OnRetry (added in the prior fix #12914) exercises POST JSON → 500 → 200 against WireMock — exactly the failing scenario. But WireMock loopback HTTP/1.1 + SocketsHttpHandler doesn't dispose request.Content after SendAsync returns, so the test passes whether the bug is present or not. I verified this with a diagnostic DelegatingHandler that captured the disposal state.

The new regression test wraps HttpClientHandler in a ContentDisposingHandler that explicitly disposes request.Content after base.SendAsync returns — reproducing production HTTP/2 behavior reliably. Confirmed: without this PR's fix, the new test throws the exact customer stack; with the fix, all 16 RetriesTests pass.

Test plan

• Local: ported template into seed/csharp-sdk/bytes-upload, ran dotnet test --filter RetriesTests → 16/16 pass
• Reverted the fix temporarily, re-ran the new regression test → fails with ObjectDisposedException at CloneRequestAsync → CopyToAsync (matches customer stack exactly)
• Re-applied the fix, all 16 tests pass
• CI: update-seed.yml regenerates all 136 csharp-sdk fixtures, runs the full test suite
• Verify with Basis-Theory after release (their reproduction is non-local — they were unable to repro outside production)

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🚩 Seed test outputs not updated to reflect template changes

The REVIEW.md states: "When a template file changes, corresponding seed test outputs should also be updated (either via seed test or bulk update)." The RawClient.Template.cs and RetriesTests.Template.cs templates were modified, but the generated copies in seed/csharp-sdk/*/src/*/Core/RawClient.cs and seed/csharp-sdk/*/src/*.Test/Core/RawClientTests/RetriesTests.cs still contain the old code (e.g., no Math.Max, no ContentDisposingHandler class, no cancellation token in CloneRequestAsync). These should be regenerated before merge.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[github-actions]

SDK Generation Benchmark Results

Comparing PR branch against median of 5 nightly run(s) on main (latest: 2026-06-10T05:30:02Z).

Full benchmark table (click to expand)

Generator	Spec	main (generator)	main (E2E)	PR (generator)	Delta
csharp-sdk	square	69s (n=5)	110s (n=5)	63s	-6s (-8.7%)

main (generator): generator-only time via --skip-scripts (includes Docker image build, container startup, IR parsing, and code generation — this is the same Docker-based flow customers use via fern generate). main (E2E): full customer-observable time including build/test scripts (nightly baseline, informational). Delta is computed against generator-only baseline.
⚠️ = generation exited with a non-zero exit code (timing may not reflect a successful run).
Baseline from nightly runs on main (latest: 2026-06-10T05:30:02Z). Trigger benchmark-baseline to refresh.
Last updated: 2026-06-10 22:33 UTC