Introduction

When one method becomes asynchronous, it often pushes async outward to its callers. That is usually not a flaw in the language. It is a sign that the caller depends on work that has not finished yet, so the real design question is where the async boundary should live and whether the caller truly needs the result immediately.

Accept That Some Async Propagation Is Correct

If a method performs asynchronous I/O and the caller needs the result before it can continue, then the caller also needs to be asynchronous. There is no safe trick that preserves non-blocking behavior while pretending the dependency is synchronous.

This is why "async all the way" is often the right answer for request handlers, service methods, and UI workflows that naturally depend on asynchronous operations.

1public class UserService
2{
3    public async Task<UserDto> GetUserAsync(int id)
4    {
5        await Task.Delay(20);
6        return new UserDto { Id = id, Name = "Ava" };
7    }
8}
9
10public async Task<IResult> GetUserEndpoint(int id, UserService service)
11{
12    var user = await service.GetUserAsync(id);
13    return Results.Ok(user);
14}
15
16public record UserDto
17{
18    public int Id { get; init; }
19    public string Name { get; init; } = string.Empty;
20}

In code like this, the async boundary belongs at the endpoint because the endpoint genuinely depends on the asynchronous result.

Return the Task Directly When You Are Only Forwarding

Sometimes a method is marked async even though it only forwards another async call. If you do not need local await, exception transformation, or cleanup, return the task directly.

1public Task<UserDto> GetUserForwardingAsync(int id)
2{
3    return _service.GetUserAsync(id);
4}

This does not make the operation synchronous. It simply avoids an unnecessary wrapper state machine while keeping the correct asynchronous contract.

Move Work Off the Immediate Call Path

If the caller does not actually need the result right now, redesign the interaction instead of fighting the signature. Common examples include audit logging, cache warming, or outbound notifications.

In those cases, a background queue is often a better boundary than a fake sync wrapper:

1public interface IBackgroundQueue
2{
3    ValueTask EnqueueAsync(Func<CancellationToken, Task> workItem);
4}
5
6public async Task SubmitAuditEventAsync(
7    AuditEvent evt,
8    IBackgroundQueue queue)
9{
10    await queue.EnqueueAsync(async ct =>
11    {
12        await _auditRepository.WriteAsync(evt, ct);
13    });
14}

Now the request path stays async where needed, but the outer caller no longer waits for a side effect it does not immediately care about.

Use Narrow Sync Adapters Only at Real Legacy Boundaries

Sometimes you do have a synchronous boundary you cannot change, such as an older interface, a library callback, or a startup hook. In that case, isolate the blocking behavior in one adapter layer instead of spreading it across the codebase.

1public UserDto GetUserSync(int id)
2{
3    return _service.GetUserAsync(id)
4        .ConfigureAwait(false)
5        .GetAwaiter()
6        .GetResult();
7}

This is not ideal. It blocks a thread and can still be dangerous in the wrong environment. But if a synchronous boundary is truly unavoidable, keeping the compromise narrow is much safer than turning blocking calls into a general pattern.

Choose the Right Design Question

When developers say "I do not want async to spread up the stack," the deeper question is usually one of these:

• does the caller really need the result immediately
• is this method only forwarding another task
• should the work be queued instead of awaited
• is there an unavoidable legacy synchronous boundary

Once you ask the right question, the implementation usually becomes obvious. The mistake is treating async propagation itself as the bug.

Common Pitfalls

The most common mistake is using .Result or .Wait() broadly just to avoid changing method signatures. That trades one inconvenience for deadlock risk and lost scalability.

Another common issue is wrapping async work in Task.Run just to preserve a synchronous-looking API. That usually hides the design problem rather than solving it. Developers also sometimes keep async on simple forwarding methods even when they could return the task directly and keep the code smaller.

Summary

• Async propagation is normal when the caller genuinely depends on unfinished I/O.
• Return the task directly when a method is only forwarding another async call.
• Move side-effect work to a background queue when the caller does not need the result now.
• Use blocking sync adapters only at narrow legacy boundaries you cannot change.
• Optimize the async boundary design rather than trying to erase async semantics everywhere.