saveRun is last-write-wins: concurrent evaluations can silently clobber recorded outcomes

[briananderson1222]

Problem

saveRun persists a run as a plain whole-file writeJson of state + manifest + report with no compare-and-swap and no locking (dist/runtime/flow-run-store.js:160-164 in 1.3.0/1.4.x), and consumers hold no mutex around evaluate. Two concurrent evaluations of the same run — e.g. an in-process REST evaluate racing an out-of-process flow CLI against the same .flow/runs/<id>/ — are last-write-wins: one evaluation's recorded gate outcomes and transitions can be silently clobbered by the other's stale snapshot.

This is a run-integrity hazard (lost outcomes in the file of record), distinct from any consumer-side staleness. Found while reviewing a downstream consumer's post-evaluation read path; the consumer's own exposure is bounded (its read strictly follows its own write and can only observe newer true state), but the underlying store cannot protect two writers from each other.

Suggested direction

Either CAS on a run revision (reject the save if the on-disk revision moved; caller re-reads and re-applies), or an advisory lock file per run dir held across read-evaluate-write. Even detection-only (warn on revision mismatch) beats silent clobber.

[briananderson1222]

Executed evidence from a downstream upgrade-mapping pass (2026-08-01): flow 3.x structurally addresses this. saveRun is unexported since 3.1.0 and every mutation is wrapped in withRunMutationLock — a cross-process filesystem ticket protocol with staleness quarantine and a recovery fence (3.12.0 dist/runtime/flow-run-store.js:1239-1341); a live .mutation.lock/ directory is observable in real Builder run dirs. The 1.3.0/1.4.x last-write-wins exposure this issue describes remains for consumers on those lines (and for any consumer hand-driving evaluations), which is one reason the downstream is planning the 3.x bump. One residual worth noting for 3.x itself: two DIFFERENT 3.x versions (e.g. 3.9.0 and 3.12.0, whose recovery-input assertions differ) writing the same run dir share the lock protocol but not identical fence semantics — downstream is pinning a single version to avoid the skew rather than testing it.