Performance: remove unnecessary Task.Run from payload unary interception

[berndverst]

Fixes #774

Summary

PayloadInterceptor.AsyncUnaryCall unconditionally wrapped request-payload externalization + continuation invocation in Task.Run(async () => {...}), forcing a thread-pool hop on every unary gRPC call even when externalization completes synchronously (the common case, since most requests don't exceed the large-payload threshold).

This PR replaces the Task.Run wrapper with a directly-invoked local async function (StartCallAsync()), removing the thread-pool dispatch while keeping the exact same internal sequence: externalize first, then invoke the continuation only if externalization succeeds.

Why behavior is unchanged

• Externalization ordering: still externalize-then-continuation, unchanged.
• Exceptions/cancellation: async state-machine semantics (including OperationCanceledException → faulted/canceled task) are identical whether the async method is invoked via Task.Run or called directly — only the scheduling (inline vs. thread-pool) differs, not the resulting Task state.
• Response headers / status / trailers / disposal: ResponseAsync, ResponseHeadersAsync, GetStatus, GetTrailers, and Dispose all continue to read from the same startCallTask, untouched by this change.
• Public API: no signature or visibility changes.

Tests

Added test/Worker/Grpc.Tests/PayloadInterceptorTests.cs (home chosen because this project already has a conditional ProjectReference to AzureBlobPayloads for compatible target frameworks) covering:

• Success path: externalize → continuation → resolve ordering, response payload, headers, status, trailers.
• Externalization failure: continuation is skipped, original exception propagates via ResponseAsync, status reflects the failure.
• Cancellation: pre-cancelled token short-circuits externalization, continuation is skipped, OperationCanceledException propagates, status is Cancelled.
• Disposal before completion: Dispose() called before the inner call exists is safely deferred and applied once available.
• Disposal after externalization failure: Dispose() is a no-op, does not throw.
• Regression test proving externalization and the continuation now run inline on the calling thread rather than being dispatched to the thread pool (verified this test fails against the prior Task.Run-based implementation, confirming it's a meaningful regression guard).

All 143 tests in Worker.Grpc.Tests pass locally.

[Copilot]

Pull request overview

This PR removes an unconditional Task.Run from the Azure Blob payload interceptor’s unary call path to eliminate a thread-pool hop on every gRPC unary call, while preserving the ordering and error/cancellation behavior of request externalization and continuation invocation.

Changes:

• Replaced Task.Run(async () => ...) with a directly-invoked local async function (StartCallAsync) in PayloadInterceptor.AsyncUnaryCall.
• Added unit tests validating ordering, exception/cancellation propagation, disposal behavior, and a regression guard ensuring synchronous externalization runs inline (no thread hop).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Extensions/AzureBlobPayloads/Interceptors/PayloadInterceptor.cs	Removes the Task.Run wrapper and starts the async externalization/continuation sequence inline to avoid a forced thread-pool dispatch.
test/Worker/Grpc.Tests/PayloadInterceptorTests.cs	Adds coverage for success/failure/cancellation/disposal flows and includes a regression test to ensure the call path remains inline when externalization is synchronous.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/Extensions/AzureBlobPayloads/Interceptors/PayloadInterceptor.cs:49

• StartCallAsync now runs ExternalizeRequestPayloadsAsync on the caller's context. While ConfigureAwait(false) here avoids resuming this method on the caller's SynchronizationContext, it does not prevent any await inside ExternalizeRequestPayloadsAsync (or helpers like MaybeExternalizeAsync/MaybeResolveAsync) from capturing that context. Previously, the Task.Run wrapper ensured these awaits ran without a SynchronizationContext. If preserving that behavior is important, consider applying ConfigureAwait(false) to awaits inside the externalization/resolve code paths as well (or otherwise ensuring they run on TaskScheduler.Default).

            // Externalize first; if this fails, do not proceed to send the gRPC call. This now runs
            // inline on the caller's thread rather than on a dedicated thread-pool thread (via
            // Task.Run), so ConfigureAwait(false) is required here to avoid capturing and resuming
            // on the caller's SynchronizationContext/TaskScheduler, matching library-safe behavior.
            await this.ExternalizeRequestPayloadsAsync(request, context.Options.CancellationToken)
                .ConfigureAwait(false);

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.