chore: replace remaining ConfigureAwait(false) with NoContext in library code - #584
Conversation
…ary code Closes out the last unresolved review comment from #561: library code uses the NoContext() extension for async continuations, but eight await sites still called ConfigureAwait(false) directly. Converts them in StoreFunctions, BaseTracer, ChannelExtensions, and the Sqlite/SqlServer projectors (whose GetConnection awaits had no configuration at all), and adds an IAsyncDisposable overload to TaskExtensions so `await using` can follow the same convention. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PR Summary by QodoReplace remaining ConfigureAwait(false) usages with NoContext convention
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
Code Review by Qodo
1.
|
Test Results 45 files + 22 45 suites +22 13m 11s ⏱️ - 3m 59s Results for commit be92051. ± Comparison against base commit 989e12d. This pull request removes 5 and adds 9 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
`await using var` always awaits the implicit DisposeAsync() unconfigured — the declaration form cannot be combined with NoContext(), only the block form can. Splits acquisition from disposal in the projectors and the paged-read enumerator so the disposal await also opts out of context capture, matching BaseTracer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Summary
Closes out the last unresolved review comment from #561 (the
.NoContext()convention flag onStoreFunctions): library code uses theNoContext()extension for async continuations, but eightawaitsites still calledConfigureAwait(false)directly.StoreFunctions,BaseTracer,ChannelExtensions, and the Sqlite/SqlServer projectors — the projectors'GetConnectionawaits previously had no configuration at all.IAsyncDisposableoverload toTaskExtensionssoawait using (enumerator.NoContext())can follow the same convention inBaseTracer.No behavior change — every edit resolves to the same
ConfigureAwait(false)under the hood.Verification
The other high-severity bot findings on #561 were checked and need no code change: the
ExchangeCacherace was already fixed in the PR itself, and the RabbitMQ concurrent-publish flag is a false positive — verified against decompiled RabbitMQ.Client 7.2.1, which serializes the wire write internally (_confirmSemaphore+ atomic frame buffer per message).🤖 Generated with Claude Code