[Audit-Medium] request-scoped services are disposed before response p…

[pepone]

AI-generated audit finding — this issue was opened from an automated security/correctness audit. It has not been triaged by a human yet; verify the reasoning, reproducibility, and severity before acting on it.

Medium: request-scoped services are disposed before response payload emission completes — CONFIRMED

Affected code:

• src/IceRpc.Extensions.DependencyInjection/Internal/DispatcherBuilder.cs:42-51 — async scope created at dispatch entry, disposed by await using when _router.DispatchAsync returns
• src/IceRpc/Internal/IceRpcProtocolConnection.cs:1078-1079 — await PerformDispatchRequestAsync(...) completes
• src/IceRpc/Internal/IceRpcProtocolConnection.cs:1101-1113 — payloadWriter.CopyFromAsync(response.Payload, ...) runs after the dispatcher lambda has returned and its scope has been disposed
• src/IceRpc/Internal/IceProtocolConnection.cs:1081-1082 — analogous post-dispatch payload read on the ice side

Verification:

Confirmed. DispatcherBuilder.Build() wraps _router.DispatchAsync in an await using ConfiguredAsyncDisposable over a fresh AsyncServiceScope. The scope is released the moment the dispatcher lambda awaits past the DispatchAsync call and returns the OutgoingResponse — which happens before the protocol connection drains response.Payload onto the wire. Concretely, the icerpc path issues payloadWriter.CopyFromAsync(response.Payload, ..., _disposedCts.Token) at IceRpcProtocolConnection.cs:1101, well after the scope's DisposeAsync has run.

Any response.Payload that lazily pulls from a scoped service (the typical pattern for streamed replies backed by EF Core, a scoped HttpClient, etc.) will encounter a disposed dependency partway through transmission.

Impact:

• Streamed responses can fail mid-body with ObjectDisposedException wrapped as InternalError on ice, or truncated reply on icerpc after headers have been sent.
• User code gets no clear diagnostic linking the failure back to the DI scope lifetime.

Recommendation:

• Hold the scope open until response payload emission completes. The cleanest implementation is a decorator on response.Payload whose Complete method disposes the scope, replacing the current await using.
• Alternatively, document and enforce that scoped services must not back deferred response payload producers.
• Add regression tests with response payloads backed by scoped disposable services.

Status: Valid, Medium severity.

---

Source report: src-IceRpc.Extensions.DependencyInjection-audit-2026-04-14.md (finding request-scoped services are disposed before response payload emission completes — **CONFIRMED**)

Severity (auditor-assigned): Medium

[pepone]

further Claude analysis

Confirmed the bug and the shape of the fix, but the fix is non-trivial and touches a hot path — worth thinking through before committing to an approach.

Flow (confirmed)

1. DispatcherBuilder.Build() creates an AsyncServiceScope, installs it on the request via IServiceProviderFeature, and wraps it in await using. When the lambda returns the OutgoingResponse, the scope is disposed.
2. IceRpcProtocolConnection then calls payloadWriter.CopyFromAsync(response.Payload, ...) and response.PayloadContinuation! — both running after the scope has already been disposed.
3. The ice-protocol path at IceProtocolConnection has the same shape (ReadFullPayloadAsync runs after scope disposal).

Any response payload that lazily pulls from a scoped service (streaming from EF Core, from a scoped HttpClient, etc.) hits ObjectDisposedException partway through transmission.

Fix shape — straightforward in principle, knotty in practice

The audit's suggestion (decorate response.Payload and dispose the scope on Complete) is the right shape, but with a few wrinkles worth flagging:

1. Two payloads, one scope. Both Payload and PayloadContinuation can read from the scope. The scope must live until the last one completes. Either wrap only the last-to-run (PayloadContinuation if non-null, else Payload) or use a ref-counted holder across both. Middleware reassigning these mid-flight makes "wrap only the last" fragile; ref-counting is safer but more code.
2. PipeReader.Complete(Exception?) is synchronous, AsyncServiceScope.DisposeAsync is async. We'd either fire-and-forget (_ = _scope.DisposeAsync().AsTask() — swallows any dispose exception) or override CompleteAsync (but most callers use Complete). Neither is clean.
3. Error paths. If the dispatcher throws before returning a response, the scope still needs to dispose. The current await using handles this naturally; a decorator approach needs an explicit try/catch + dispose on the exception path.
4. Both protocol paths need the fix. icerpc streams the payload out after dispatch returns; ice reads the full payload after dispatch returns. Same bug, same fix shape.

Open question — is it worth the invasive fix?

Streamed Slice responses are a first-class feature, but whether they're commonly backed by scoped DI services in IceRpc deployments in practice determines whether this is must-fix or edge case. The alternative to the decorator fix is documenting the limitation: scoped services should not back deferred response payload producers, and streamed responses should materialize their data inside the dispatcher (under the scope) rather than relying on lazy reads.

Leaning toward the decorator fix because the quiet-mid-stream failure mode is exactly the kind of bug users can't easily diagnose. But marking this as "think more before coding" rather than opening a PR immediately — the fire-and-forget sync-vs-async-dispose corner is worth a second opinion before we commit to shape.