Which Async.Parallel strategy ensures deterministic execution in build pipelines?

The direct answer

Async.Parallel does not provide any mechanism to guarantee the execution sequence of side effects. Its only ordering guarantee is on the results: the returned array matches the order of the input sequence, regardless of which task finished first. Task start order, interleaving, and the order in which effects (console writes, file writes, log entries) occur are all non-deterministic and vary with thread pool scheduling, machine load, and task delays.

So the correct strategy is not to find a switch inside Async.Parallel, but to separate concurrent work from ordered effects.

The pattern that gives you both

Keep the parallel tasks pure (or as pure as practical) and have each return its output tagged with its input index. After Async.Parallel completes, sort by index and apply the side effects — logging, audit records, artifact commits — sequentially in a single, deterministic phase:

let runTask (i, input) = async {
    let! artifact = build input          // concurrent, no shared writes
    return (i, artifact, [sprintf "built %s" input.Name])
}

let pipeline inputs = async {
    let! results =
        inputs
        |> List.indexed
        |> List.map runTask
        |> Async.Parallel
    results
    |> Array.sortBy (fun (i, _, _) -> i)
    |> Array.iter (fun (_, artifact, logs) ->
        logs |> List.iter logSink.Write   // single ordered writer
        commit artifact)                  // deterministic commit order
}

This preserves full concurrency where it is safe and gives byte-identical logs across runs. If effects genuinely must be ordered during execution, the honest options are Async.Sequential (which sacrifices parallelism), or a single MailboxProcessor that owns the shared resource while tasks post messages to it — the mailbox serializes the effects even though the work stays parallel. Note that merely limiting the degree of parallelism does not create ordering; two tasks can still interleave arbitrarily.

What Async.SwitchToContext does — and doesn't do

Async.SwitchToContext only changes where continuations run (for example, onto a UI thread's synchronization context). It is not an ordering primitive. Implications for build pipelines:

• In console apps and typical CI agents, SynchronizationContext.Current is null, so continuations resume on the thread pool — which is exactly why observed effect order drifts between runs and machines.
• Switching to a single-threaded context can serialize continuations, but this is a side effect of that context, not a contract, and it introduces deadlock risk if anything blocks synchronously on the async (a classic problem under UI or legacy ASP.NET contexts).
• Calling SwitchToContext inside parallel tasks can make interleaving less predictable, not more, because you are now subject to two schedulers.

For a build pipeline, the practical advice is: don't use context switching as a coordination tool. If you must capture a context, do it once at the entry point, and keep the parallel body context-free.

Verifying determinism

Inject random delays into each task (do! Async.Sleep (Random().Next 50)), record thread ID, timestamp, and task index per effect, and run the pipeline repeatedly. You should see the result array stable while raw effect order scrambles — confirming the need for the ordered flush phase. After refactoring to a single ordered sink, diff the logs across runs; they should be identical. Also check SynchronizationContext.Current at entry under your console host, test runner, and CI agent, since behavior can differ between them.

Remaining pitfalls

Even with ordered results, shared mutable caches, direct console writes, file locks, and test-framework listeners can reintroduce races. Route every effect through the ordered commit phase or the mailbox. One caution: surface area such as optional parallelism limits on Async.Parallel is version-sensitive — confirm against the FSharp.Core version your pipeline actually references rather than assuming availability.