Repository navigation
WFC17 fails only when packages/cli runs beside three other suites #508
Description
WFC17: the bundle decides compatible reuse fails when packages/cli/ runs beside three other package suites in one deno test invocation, and passes when its own file runs alone. It is not specific to any branch's changes: the diff it failed under touches no workflow file.
The failing command
deno task test packages/core/ packages/testing/ packages/cli/ packages/test-agent/FAILED | 335 passed (2682 steps) | 1 failed (1 step) (8m10s)
Tier WFC — a workflow closed over a component bundle ... WFC17: the bundle decides compatible reuse
The passing isolated rerun
Same revision, same machine, immediately afterwards:
deno task test packages/cli/tests/workflow-cli.test.tsWFC19: a resume whose pinned components are unreachable is refused whole ... ok (3s)
Tier WFC — a workflow closed over a component bundle ... ok (17s)
ok | 2 passed (19 steps) | 0 failed (57s)
Environment
deno 2.9.5 (stable, release, aarch64-apple-darwin)- Revision:
3db4536516601305ccf99f216d88967b8d7302af(branchagent/issue-454-rework, parent6bdc271ae96ff9afe2d1b28b6cd8987879bd828c) - macOS, local worktree
/private/tmp/xmd-501-impl
Why this is worth a look
WFC17 starts a workflow run through the xmd CLI in a fixture and then starts a
second one that must reuse the first's bundle, so it spawns subprocesses and
touches real run storage. Running four package suites in one invocation puts
several subprocess-heavy CLI tests on the machine at once, which is the condition
that distinguishes the failing run from the passing one. That places it with the
other load-dependent CLI cases — see #275 and #343 — rather than with a defect in
what it asserts.
The aggregate command is not a CI job: CI runs test-deno, test-node and
test-bun on separate runners. It is what an implementor runs locally to check a
change's blast radius, so the cost of the flake is a false signal during review
rather than a red pipeline.
What would settle it: capture the failure output (the assertion, not just the
title) under the aggregate command, and check whether the reused run id or its
storage root is what diverges under concurrency.
Activity
taras commentedon Aug 20, 2026
Investigated on
mainat 0976a09, deno 2.9.5, same machine class (aarch64-apple-darwin).Reproduction attempts — both green
The exact failing command, on an otherwise idle machine:
WFC17 took 4s inside that aggregate — the same as alone. Note the aggregate is not concurrent with itself:
deno task testruns test files serially (no--parallel), so four suites in one invocation put only one test on the machine at a time. The "several subprocess-heavy CLI tests at once" condition has to come from outside the invocation — e.g. other sessions' batteries sharing the machine, which is what the original environment (/private/tmp/xmd-501-impl, multi-worktree era) had.Reconstructing that:
workflow-cli.test.tsrun whilepackages/core/andpackages/test-agent/suites ran concurrently beside fourgitfork/exec churn loops (load average 20):Still 12× headroom against the harness's 60s per-invocation deadline.
The run id / storage root question
Nothing in the reuse path can diverge under concurrency:
conflictingFields(packages/workflow/src/storage/compatibility.ts) — run id, definition descriptor (commitobjectId, bundle, target), base, canonical props. No wall clock, no environment, no shared state.XMD_WORKFLOW_RUNS, an isolatedtmpdir()/xmd-wfc-<uuid>per test; the run id is the explicit--id=loop-2. No other test can reach either.tryLockSyncon an fd the process owns; the kernel releases it at exit, and the fixture'sxmdinvocations are sequential.So if the failure was an assertion mismatch, the assertion text would have named something none of these can produce — which is why the missing output matters.
What was load-sensitive: the harness, and it destroyed the evidence
The only clock anywhere in WFC17 is the suite harness's own:
runCliwraps eachxmdsubprocess in a 60s timebox, and on expiry it threwxmd … timed out after 60000msand discarded everything the child wrote. If that is what happened here, the failure was structurally anonymous — indistinguishable from any other timeout, with no way to tell whether the child hung beforeworkflow run: loop-2was reported or after.#509 closes that hole: an expired deadline now reports the host's load average and both channels as received up to abandonment. The next occurrence of this flake — timeout or assertion — will carry the output this issue asked for. The 60s deadline itself is unchanged.