ValueTask C# Double-Await Bug — Duplicate Payments

Every .NET application that does any I/O — database queries, HTTP calls, file reads — leans heavily on async/await. Task<T> is the workhorse of that system, and it works brilliantly. But there's a hidden cost baked into every Task: a heap allocation. For the vast majority of application code, that cost is irrelevant. For high-throughput library code — think ASP.NET Core's Kestrel web server, gRPC pipelines, or a caching layer handling millions of requests per second — those allocations become the bottleneck that separates 50,000 RPS from 500,000 RPS.

ValueTask was introduced in .NET Core 2.0 (and backported via the System.Threading.Tasks.Extensions NuGet package for .NET Standard) specifically to solve the 'synchronous fast path' problem. When a method is async but frequently returns a cached or already-computed result without ever actually suspending, wrapping that result in a full Task object is wasteful. ValueTask is a struct — it lives on the stack or inline in another object — so when the result is synchronous, there's zero heap allocation at all. When the result truly is asynchronous, ValueTask can delegate to a pooled IValueTaskSource, avoiding a fresh heap allocation even in the async path.

By the end of this article you'll understand exactly how ValueTask works at the struct and IValueTaskSource level, when to reach for it versus Task, how to benchmark the difference yourself, and — critically — the three production mistakes that will cause hard-to-diagnose bugs if you get them wrong.

What ValueTask Actually Does — And Why Double-Await Breaks Payments

ValueTask<T> is a value-type alternative to Task<T> that can wrap either a synchronous result or an asynchronous operation. Its core mechanic: it avoids allocating a heap object when the result is available synchronously — a common case in caching, fast I/O, or validation checks. But unlike Task, ValueTask is not designed for multiple awaits. Awaiting a ValueTask more than once is undefined behavior: the underlying object (like IValueTaskSource) may be reused or recycled, causing corruption, duplicate execution, or silent data loss.

In practice, ValueTask<T> can be backed by a Task<T> or a custom IValueTaskSource. When backed by a reusable source (e.g., pooled async state machines), the first await consumes the operation. A second await may read stale state, trigger the operation again, or throw. The compiler does not warn you. The runtime does not protect you. It is your responsibility to ensure each ValueTask is awaited exactly once.

Use ValueTask<T> when you have a hot path where the result is often synchronous and allocation pressure matters — think cache hits, memory reads, or simple computations. For general-purpose async methods, especially those exposed across public APIs, stick with Task<T>. The performance gain from ValueTask is real but narrow; misuse in production systems — like duplicate payment processing from double-awaiting a network call — is catastrophic and silent.

How Task Allocates and Why That Hurts at Scale

Before ValueTask makes sense, you need to feel the pain it solves. Every time you write return Task.FromResult(value), the runtime allocates a new Task<T> object on the managed heap. The JIT can cache Task<bool> for true/false, and Task<int> for small integers (0–9 in current runtimes), but anything beyond those tiny pools creates a fresh object. That object then requires garbage collection.

In a hot path — say, a method called 100,000 times per second where 95% of calls hit an in-memory cache — you're creating 95,000 Task objects per second that immediately become garbage. Each collection pause, however brief, adds latency jitter. Kestrel's design documents explicitly cite this as why ValueTask<T> was adopted throughout the pipeline.

The struct nature of ValueTask is the key. A struct value type doesn't need a heap allocation on its own — it can sit inside another struct, on the stack frame, or inline in a class field. When your method returns synchronously, ValueTask<T> stores the T value directly inside its own fields. No Task object, no GC pressure. When the method truly suspends, ValueTask holds a reference to either a Task or an IValueTaskSource — so you pay the allocation cost only when you genuinely need it.

using System;
using System.Threading.Tasks;
using System.Runtime.CompilerServices;

public class AllocationComparison
{
    private static readonly string? _cachedGreeting = "Hello, World!";

    public static Task<string> GetGreetingWithTask(bool forceAsync)
    {
        if (!forceAsync && _cachedGreeting is not null)
        {
            return Task.FromResult(_cachedGreeting);
        }
        return SimulateSlowDatabaseCallAsync();
    }

    public static ValueTask<string> GetGreetingWithValueTask(bool forceAsync)
    {
        if (!forceAsync && _cachedGreeting is not null)
        {
            return new ValueTask<string>(_cachedGreeting);
        }
        return new ValueTask<string>(SimulateSlowDatabaseCallAsync());
    }

    private static async Task<string> SimulateSlowDatabaseCallAsync()
    {
        await Task.Delay(50);
        return "Hello from database!";
    }

    public static async Task Main(string[] args)
    {
        int iterations = 100_000;
        long gcBefore, gcAfter;

        GC.Collect();
        gcBefore = GC.CollectionCount(0);

        for (int i = 0; i < iterations; i++)
        {
            string result = await GetGreetingWithTask(forceAsync: false);
            _ = result;
        }

        gcAfter = GC.CollectionCount(0);
        Console.WriteLine($"Task path — Gen0 GC collections: {gcAfter - gcBefore}");

        GC.Collect();
        gcBefore = GC.CollectionCount(0);

        for (int i = 0; i < iterations; i++)
        {
            string result = await GetGreetingWithValueTask(forceAsync: false);
            _ = result;
        }

        gcAfter = GC.CollectionCount(0);
        Console.WriteLine($"ValueTask path — Gen0 GC collections: {gcAfter - gcBefore}");
    }
}

ValueTask Internals — The Struct Layout and IValueTaskSource

ValueTask<T> is defined in the BCL as a readonly struct with three fields: an object? _obj, a T _result, and a short _token. This tiny layout is the key to understanding every rule about using it correctly.

When _obj is null, the value is synchronous and _result holds the answer directly — zero indirection, zero heap lookup. When _obj is a Task<T>, you're wrapping a standard task — same allocation as before, but at least the API stays uniform. When _obj implements IValueTaskSource<T>, you're holding a reference to a pooled object — this is the advanced path used by .NET's own I/O pipelines via AwaitableSocketAsyncEventArgs and similar types.

IValueTaskSource<T> is the interface that enables the pooling trick. An object implementing it can be returned from a pool, used for one await cycle, then returned to the pool. The _token field is a version counter — it increments each time a pooled source is recycled. This is why the 'only await once' rule exists: if you await a ValueTask a second time after the source has been recycled and reissued to another caller, the _token will have changed and you'll either get an InvalidOperationException (if the runtime checks it) or silent data corruption (if it doesn't). This is not hypothetical — it's a documented, real bug class.

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Threading.Tasks.Sources;
using System.Collections.Generic;

public class PooledValueTaskSource : IValueTaskSource<int>
{
    private short _currentToken;
    private int _result;
    private bool _isCompleted;
    private Action<object?>? _continuation;
    private object? _continuationState;

    public int GetResult(short token)
    {
        if (token != _currentToken)
            throw new InvalidOperationException(
                "ValueTask was awaited after its underlying source was recycled. " +
                "Never await the same ValueTask more than once.");

        if (!_isCompleted)
            throw new InvalidOperationException("Result not yet available.");

        int capturedResult = _result;
        _currentToken++;
        _isCompleted = false;
        _continuation = null;
        Console.WriteLine($"[Pool] Source recycled. New token is {_currentToken}.");

        return capturedResult;
    }

    public ValueTaskSourceStatus GetStatus(short token)
    {
        if (token != _currentToken)
            throw new InvalidOperationException("Stale token — source has been recycled.");
        return _isCompleted ? ValueTaskSourceStatus.Succeeded : ValueTaskSourceStatus.Pending;
    }

    public void OnCompleted(
        Action<object?> continuation,
        object? state,
        short token,
        ValueTaskSourceOnCompletedFlags flags)
    {
        _continuation = continuation;
        _continuationState = state;
    }

    public void SignalCompletion(int result)
    {
        _result = result;
        _isCompleted = true;
        Console.WriteLine($"[Source] Signalled completion with result: {result}");
        _continuation?.Invoke(_continuationState);
    }

    public ValueTask<int> AsValueTask() => new ValueTask<int>(this, _currentToken);
}

public class IValueTaskSourceDemo
{
    public static async Task Main(string[] args)
    {
        var source = new PooledValueTaskSource();
        var backgroundWork = Task.Run(async () =>
        {
            await Task.Delay(100);
            source.SignalCompletion(result: 42);
        });

        ValueTask<int> valueTask = source.AsValueTask();
        Console.WriteLine("[Main] Awaiting ValueTask...");
        int answer = await valueTask;
        Console.WriteLine($"[Main] Result: {answer}");

        try
        {
            int staleAnswer = await valueTask;
            Console.WriteLine($"[Main] Stale result: {staleAnswer}");
        }
        catch (InvalidOperationException ex)
        {
            Console.WriteLine($"[Main] Caught expected error: {ex.Message}");
        }

        await backgroundWork;
    }
}

Task vs ValueTask — Decision Rules You Can Actually Apply in Code Reviews

The single biggest mistake developers make with ValueTask is using it everywhere because it sounds 'better'. It isn't always. ValueTask introduces real constraints: no awaiting twice, no blocking with .Result or .GetAwaiter().GetResult(), and a struct-copy footgun. If you misuse it, you don't get a compiler error — you get a runtime bug under load.

Here's the mental model: ValueTask earns its keep when a method has a synchronous fast path that's hit significantly more often than the async path. The classic examples are cache lookups, buffer reads from a pipe that's already filled, and semaphore acquisitions that rarely actually wait. The BCL uses it for Stream.ReadAsync, Socket.ReceiveAsync, and all of System.IO.Pipelines for exactly this reason.

Task is the right choice when: the method is almost always genuinely async, when multiple callers will await the same result (fan-out), when you need to call .Result or .Wait() synchronously (don't, but sometimes you inherit legacy code), or when the method is simple application-layer code where the allocation cost is unmeasurable next to actual I/O latency. Don't let premature optimization drive you to ValueTask in your UserService. Do use it in a high-frequency cache abstraction you're building.

using System;
using System.Collections.Concurrent;
using System.Threading.Tasks;
using System.Net.Http;

public class HttpResponseCache
{
    private readonly HttpClient _httpClient;
    private readonly ConcurrentDictionary<string, string> _cache = new();

    public HttpResponseCache(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public ValueTask<string> GetContentAsync(string url)
    {
        if (_cache.TryGetValue(url, out string? cachedContent))
        {
            Console.WriteLine($"[Cache] HIT for {url} — no allocation, no await suspension");
            return new ValueTask<string>(cachedContent);
        }

        Console.WriteLine($"[Cache] MISS for {url} — initiating HTTP request");
        return new ValueTask<string>(FetchAndCacheAsync(url));
    }

    private async Task<string> FetchAndCacheAsync(string url)
    {
        string content = await _httpClient.GetStringAsync(url);
        _cache[url] = content;
        Console.WriteLine($"[Cache] Stored {content.Length} chars for {url}");
        return content;
    }
}

public class FanOutExample
{
    public static async Task DemonstrateWhyTaskWinsForFanOut(HttpResponseCache cache)
    {
        string url = "https://example.com";
        Task<string> sharedTask = cache.GetContentAsync(url).AsTask();

        string firstResult = await sharedTask;
        string secondResult = await sharedTask;
        Console.WriteLine($"Fan-out result 1: {firstResult.Substring(0, Math.Min(30, firstResult.Length))}...");
        Console.WriteLine($"Fan-out result 2 (same task): {secondResult.Substring(0, Math.Min(30, secondResult.Length))}...");
    }

    public static async Task Main(string[] args)
    {
        using var httpClient = new HttpClient();
        var cache = new HttpResponseCache(httpClient);
        string content1 = await cache.GetContentAsync("https://example.com");
        Console.WriteLine($"First call — got {content1.Length} chars\n");
        string content2 = await cache.GetContentAsync("https://example.com");
        Console.WriteLine($"Second call — got {content2.Length} chars\n");
        await DemonstrateWhyTaskWinsForFanOut(cache);
    }
}

Benchmarking, Async State Machine Impact, and the Non-Generic ValueTask

A ValueTask returned from a non-async method (one that returns new ValueTask<T>(value)) genuinely has zero allocation overhead. But there's a subtlety: if your method is marked async, the compiler generates a state machine struct regardless of whether you use Task or ValueTask. That state machine itself gets heap-allocated when the method suspends. So async ValueTask<T> only avoids the Task wrapper allocation — the state machine allocation still occurs if you await.

This means the allocation win of ValueTask is exclusively on the synchronous, non-awaiting fast path. If your method is always async and always suspends, ValueTask gives you no benefit at all over Task — and adds cognitive overhead with its constraints. Measure before you change.

The non-generic ValueTask (without <T>) was added alongside ValueTask<T> and serves async void-style fire-and-forget operations that should still be awaitable. Think of it as a zero-allocation replacement for Task (not Task<T>) in methods that frequently complete synchronously — like a FlushAsync that's usually a no-op because the buffer is empty. Use [AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder<>))] on your method in .NET 6+ to also pool the state machine itself, squeezing out even the state machine allocation on the async path.

// Install BenchmarkDotNet: dotnet add package BenchmarkDotNet
// Run with: dotnet run -c Release
// The [MemoryDiagnoser] attribute is what shows you allocations per operation.

using System;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]
[RankColumn]
public class ValueTaskBenchmarks
{
    private const int CachedValue = 99;

    [Benchmark(Baseline = true)]
    public async Task<int> GetWithTask()
    {
        return await Task.FromResult(CachedValue);
    }

    [Benchmark]
    public async ValueTask<int> GetWithValueTask()
    {
        return await new ValueTask<int>(CachedValue);
    }

    [Benchmark]
    [AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder<int>))]
    public async ValueTask<int> GetWithPooledValueTask()
    {
        return await new ValueTask<int>(CachedValue);
    }

    [Benchmark]
    public async ValueTask<int> GetWithValueTaskActuallyAsync()
    {
        await Task.Yield();
        return CachedValue;
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        BenchmarkRunner.Run<ValueTaskBenchmarks>();
    }
}

ValueTask and AsyncLocal: The Hidden Bug

AsyncLocal<T> flows logical execution context across async boundaries. With Task, the flow is well-understood — AsyncLocal values propagate through the Task's internal execution context. With ValueTask backed by an IValueTaskSource, there's a subtle trap: when the source is recycled, the AsyncLocal values may be stale or belong to a different operation.

Consider a logging framework that stores a CorrelationId in AsyncLocal<string>. If you await a recycled IValueTaskSource, the continuation may run on a different logical context, and the AsyncLocal value might be from the previous invocation that recycled the source. This leads to log correlation failures — the typical symptom is logs showing inconsistent correlation IDs across the same request.

The fix is to capture the logical call context before creating the ValueTask if you must reuse sources, or simply avoid storing ValueTask across awaits. This is another reason why the single-await rule is critical: each await should be the only one on that ValueTask, and the AsyncLocal context flows correctly because the continuation is tied to the original caller's execution context.

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Threading.Tasks.Sources;

public class AsyncLocalBugDemo
{
    private static readonly AsyncLocal<string> _correlationId = new();

    public static async Task Main()
    {
        // Simulate a pooled source
        var source = new SimplePooledValueTaskSource();

        // Task 1 sets correlation ID
        var task1 = Task.Run(async () =>
        {
            _correlationId.Value = "req-001";
            Console.WriteLine($"Task1: Before await, CorrelationId = {_correlationId.Value}");
            await source.AsValueTask();
            Console.WriteLine($"Task1: After await, CorrelationId = {_correlationId.Value}");
        });

        // Task 2 sets a different correlation ID
        var task2 = Task.Run(async () =>
        {
            await Task.Delay(50); // ensure task1 starts first
            _correlationId.Value = "req-002";
            Console.WriteLine($"Task2: Before await, CorrelationId = {_correlationId.Value}");
            await source.AsValueTask();
            Console.WriteLine($"Task2: After await, CorrelationId = {_correlationId.Value}");
        });

        await Task.WhenAll(task1, task2);
    }
}

// Minimal IValueTaskSource that recycles after one use
public class SimplePooledValueTaskSource : IValueTaskSource<int>
{
    private short _token;
    private int _result;
    private bool _completed;
    private Action<object?>? _continuation;
    private object? _state;

    public int GetResult(short token)
    {
        if (token != _token) throw new InvalidOperationException("Stale");
        _token++;
        return _result;
    }

    public ValueTaskSourceStatus GetStatus(short token) => _completed ? ValueTaskSourceStatus.Succeeded : ValueTaskSourceStatus.Pending;

    public void OnCompleted(Action<object?> cont, object? state, short token, ValueTaskSourceOnCompletedFlags flags)
    {
        _continuation = cont;
        _state = state;
    }

    public void SignalCompletion(int result)
    {
        _result = result;
        _completed = true;
        _continuation?.Invoke(_state);
    }

    public ValueTask<int> AsValueTask() => new(this, _token);
}

/*
Sample output (non-deterministic but illustrates the problem):
Task1: Before await, CorrelationId = req-001
Task2: Before await, CorrelationId = req-002
Task1: After await, CorrelationId = req-002  ← Wrong! The correlation leaked from task2
Task2: After await, CorrelationId = req-002
*/

ValueTask and Object Pools: You're Probably Still Allocating on Every Call

Most engineers think switching from Task to ValueTask fixes heap allocations. It doesn't. ValueTask only removes allocation when it completes synchronously. If your method awaits anything, you still burn memory — sometimes worse because ValueTask wraps a Task internally when it hits the slow path. The real win comes from combining ValueTask with object pooling via IValueTaskSource. Without it, you're just paying the struct tax for no benefit. Here's the production reality: if your cache or database call completes synchronously 90% of the time, ValueTask saves heap pressure. If it's async more than half the time, you're actually hurting throughput. Pooling swaps the allocation from per-call to a reusable slot — but you must reset state manually or corrupt the next caller. Never pool without a completion callback. Never reuse a ValueTask that's still being awaited. That's how you get silent data corruption in production. The benchmark numbers look great in isolation. They hide the memory thrash you'll see under sustained load.

// io.thecodeforge — csharp tutorial

using System;
using System.Threading.Tasks;
using System.Threading.Tasks.Sources;

public sealed class CachedResultSource : IValueTaskSource<string>
{
    private string _result;
    private ManualResetValueTaskSourceCore<string> _core;

    // Must call before every reuse — don't skip this
    public void Reset()
    {
        _core.Reset();
        _result = null;
    }

    public void SetResult(string value)
    {
        _result = value;
        _core.SetResult(value);
    }

    public string GetResult(short token)
    {
        string result = _core.GetResult(token);
        _result = null; // release reference for GC
        return result;
    }

    public ValueTaskSourceStatus GetStatus(short token) => _core.GetStatus(token);
    public void OnCompleted(Action<object?> continuation, object? state, short token, ValueTaskSourceOnCompletedFlags flags)
        => _core.OnCompleted(continuation, state, token, flags);
}

// Usage — pool this and reuse per call
var pooled = new CachedResultSource();
pooled.Reset();
pooled.SetResult("cached-data");
ValueTask<string> vt = new(pooled, pooled._core.Version);
string result = await vt;
Console.WriteLine(result); // Output: cached-data

The AsyncLocal Leak: Why Your Thread Pool Becomes a Poison Cabinet

AsyncLocal flows state across async calls. It's convenient for request IDs or tenant context. But ValueTask breaks in ways Task never did. Because Task<T> boxes the async state machine into a reference type, AsyncLocal flows correctly through continuations. ValueTask's struct layout can cause AsyncLocal data to leak between unrelated operations when the ValueTask is pooled. Here's the mechanics: when you await a pooled ValueTask, the continuation runs on the same thread pool thread. The thread's AsyncLocal still carries the previous operation's context if the pool didn't clear it. You read another user's tenant ID. You log under the wrong request. Your payment pipeline deducts from the wrong account. This isn't theoretical — I've seen it in production on a high-throughput API endpoint. The fix is brutal: disable AsyncLocal flow on pooled ValueTask completions by passing ValueTaskSourceOnCompletedFlags.None in OnCompleted. Or never pool ValueTask sources that interact with AsyncLocal. Better yet, avoid AsyncLocal entirely in hot paths. Use explicit parameters or a scoped DI container. AsyncLocal is a global variable that hides inside your thread pool.

// io.thecodeforge — csharp tutorial

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Threading.Tasks.Sources;

public class LeakySource : IValueTaskSource
{
    private ManualResetValueTaskSourceCore<object> _core;

    public void SetResult()
    {
        // BUG: AsyncLocal not cleared — previous value leaks
        _core.SetResult(null);
    }

    public void GetResult(short token) => _core.GetResult(token);
    public ValueTaskSourceStatus GetStatus(short token) => _core.GetStatus(token);

    public void OnCompleted(Action<object?> continuation, object? state, short token, ValueTaskSourceOnCompletedFlags flags)
    {
        // FIX: Pass ValueTaskSourceOnCompletedFlags.None to stop AsyncLocal flow
        _core.OnCompleted(continuation, state, token, ValueTaskSourceOnCompletedFlags.None);
    }
}

public static class Demo
{
    public static async Task Run()
    {
        AsyncLocal<string> context = new();
        context.Value = "tenant-42";

        var source = new LeakySource();
        source.SetResult();
        ValueTask vt = new(source, source.GetType().GetField("_core", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)!.GetHashCode());
        await vt;

        // Current thread's AsyncLocal still says "tenant-42" — even after the operation completed
        Console.WriteLine($"Leaked context: {context.Value}"); // Output: Leaked context: tenant-42
    }
}

Definition — ValueTask Bakes the Task Contract Into a Struct

ValueTask is a struct wrapper that can hold either a Task or a result directly, enabling zero-allocation returns when the result is synchronously available. Unlike Task<T>, which always requires a heap allocation, ValueTask<TResult> stores the result inline when it completes synchronously — a critical difference for high-throughput code paths. The struct layout contains a TResult field, a short circuit flag, an IValueTaskSource, and a Task. When the async method completes without suspension, the consumer retrieves the value directly from the struct, skipping the GC entirely. If the method suspends, the ValueTask wraps a promise object — either a Task or an IValueTaskSource — and the consumer must await exactly once. The non-generic ValueTask follows the same pattern but returns no result. This design directly attacks allocation pressure: a synchronous hot path that produces a ValueTask<int> allocates zero bytes, while Task<int> allocates at least 24 bytes per call. Understanding this fundamental difference lets you predict allocation patterns before running a profiler.

// io.thecodeforge — csharp tutorial

public struct ValueTask<TResult> {
    private readonly TResult _result;
    private readonly Task<TResult> _task;
    private readonly IValueTaskSource<TResult> _source;
    private readonly byte _token;

    public bool IsCompletedSuccessfully => _source == null && _task?.IsCompletedSuccessfully != false;
    public TResult Result => _source?.GetResult(_token) ?? (_task?.Result ?? _result);
}

Properties — IsCompletedSuccessfully Is the Only Safe Read

ValueTask<TResult> exposes four properties: IsCompletedSuccessfully, IsCompleted, IsFaulted, and IsCanceled. IsCompletedSuccessfully is the only property safe to call without consuming the instance — it returns true when the operation completed synchronously and the result is ready. The other three properties (IsCompleted, IsFaulted, IsCanceled) internally call GetResult on the backing source, which invalidates the promise for reuse. Reading them before awaiting throws InvalidOperationException with IValueTaskSource-backed implementations, or silently corrupts pooled source reuse in object-pool patterns. The synchronous path is safe: IsCompletedSuccessfully checks the _source field for null and the _task for completion without side effects. Non-generic ValueTask lacks properties entirely — you only get the .Preserve() method. In code reviews, flag any use of IsFaulted or IsCanceled on ValueTask — they force allocation and break pooling. Prefer direct await with try/catch, or call Preserve() to convert to a Task if you need multiple inspections.

// io.thecodeforge — csharp tutorial

ValueTask<int> vt = FetchAsync();

// Safe: reads struct field without side effects
if (vt.IsCompletedSuccessfully)
    return vt.Result;

// DANGER: IsFaulted calls GetResult internally
// if (vt.IsFaulted) { }  // Throws if backed by IValueTaskSource

return await vt;  // Single await, safe consumption