ValueTask C# Double-Await Bug — Duplicate Payments

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 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

IValueTaskSource for Pooling ValueTasks

The IValueTaskSource<T> interface enables pooling of ValueTask<T> instances, eliminating allocations entirely. Instead of creating a new ValueTask<T> each time an async method is called, you reuse a pooled object that implements IValueTaskSource<T>. This is critical in high-throughput scenarios like payment processing where every allocation adds GC pressure.

To implement pooling, create a class that implements IValueTaskSource<T> and manages its own state. Use ManualResetValueTaskSourceCore<T> as a helper to handle the core logic. The pool typically uses ObjectPool<T> from Microsoft.Extensions.ObjectPool.

Example: ```csharp public class PooledValueTaskSource<T> : IValueTaskSource<T> { private ManualResetValueTaskSourceCore<T> _core;

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); public T GetResult(short token) => _core.GetResult(token);

public void Reset() => _core.Reset(); public void SetResult(T result) => _core.SetResult(result); public void SetException(Exception exception) => _core.SetException(exception); }

// Usage with pool var pool = new DefaultObjectPool<PooledValueTaskSource<PaymentResult>>( new DefaultPooledObjectPolicy<PooledValueTaskSource<PaymentResult>>()); var source = pool.Get(); source.SetResult(paymentResult); return new ValueTask<PaymentResult>(source, source.Version); ```

Key points: Always reset the source before returning it to the pool. Use a version token to detect double-await. Never await a pooled ValueTask<T> more than once—it corrupts the state for the next consumer.

public class PooledValueTaskSource<T> : IValueTaskSource<T>
{
    private ManualResetValueTaskSourceCore<T> _core;

    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);
    public T GetResult(short token) => _core.GetResult(token);

    public void Reset() => _core.Reset();
    public void SetResult(T result) => _core.SetResult(result);
    public void SetException(Exception exception) => _core.SetException(exception);
}

// Usage
var pool = new DefaultObjectPool<PooledValueTaskSource<PaymentResult>>(
    new DefaultPooledObjectPolicy<PooledValueTaskSource<PaymentResult>>());
var source = pool.Get();
source.SetResult(paymentResult);
return new ValueTask<PaymentResult>(source, source.Version);

ValueTask vs Task: When Each Is Appropriate

Choosing between ValueTask<T> and Task<T> depends on the expected completion pattern and allocation sensitivity.

Use Task<T> when: - The method is likely to complete asynchronously (e.g., I/O-bound). - The method will be awaited multiple times (e.g., Task.WhenAll). - The method is part of a public API where consumers may cache or combine the task. - You need to pass the task to other methods that expect Task<T>.

Use ValueTask<T> when: - The method frequently completes synchronously (e.g., cached results, fast operations). - The method is called at high frequency and you want to avoid allocations. - The method is internal or you control all consumers. - You are implementing an async method that returns a pooled object.

Decision rules for code reviews: 1. If the method returns a Task<T> and is synchronous in the common case, consider ValueTask<T>. 2. If the method returns ValueTask<T>, ensure it is awaited only once and never stored in a field or passed to Task.WhenAll. 3. If the method is part of a library, prefer Task<T> unless you document the restrictions.

Example: ```csharp // Good: synchronous completion, high-frequency call public ValueTask<int> GetCachedCountAsync() { if (_cache.TryGetValue(out int count)) return new ValueTask<int>(count); return new ValueTask<int>(LoadCountAsync()); }

// Bad: ValueTask used in public API without restrictions public ValueTask<User> GetUserAsync(int id) // Consumers may misuse ```

Benchmark: ValueTask<T> with synchronous completion allocates 0 bytes vs Task.FromResult<T> which allocates a Task<T> object (approx 40 bytes).

// Synchronous completion example
public ValueTask<int> GetCachedCountAsync()
{
    if (_cache.TryGetValue(out int count))
        return new ValueTask<int>(count);
    return new ValueTask<int>(LoadCountAsync());
}

// Async-only example (use Task<T>)
public Task<int> LoadCountAsync()
{
    return Database.QueryAsync<int>("SELECT COUNT(*) FROM ...");
}

ValueTask Restrictions and Common Mistakes

ValueTask<T> is a struct that can wrap either a T result, a Task<T>, or an IValueTaskSource<T>. This design imposes several restrictions that developers often overlook.

Restrictions: 1. Single await only: A ValueTask<T> instance must be awaited exactly once. Awaiting it twice throws an InvalidOperationException or returns corrupted data (especially with pooled sources). 2. No concurrent access: Do not await the same ValueTask<T> from multiple threads simultaneously. 3. No caching or storing: Do not store a ValueTask<T> in a field or collection. Convert to Task<T> if you need to cache. 4. No blocking: Do not call .Result or .GetAwaiter().GetResult() on a ValueTask<T> that wraps an async operation—it may deadlock.

// Bad: double await
ValueTask<int> vt = GetValueAsync();
await vt;
await vt; // Throws InvalidOperationException

// Bad: stored in field
private ValueTask<int> _vt;

// Good: convert to Task for caching
private Task<int> _task;
public async Task UseAsync()
{
    _task = GetValueAsync().AsTask();
    await _task;
}

// Bad: used with Task.WhenAll
ValueTask<int> vt1 = GetValueAsync();
ValueTask<int> vt2 = GetValueAsync();
await Task.WhenAll(vt1, vt2); // Boxes and may cause issues