[roodboi]

Root cause

The P01 scenario failed on CI (PR #341, run 39435455774, job 118671149247, docker-e2e shard 3/4) at the start of the killed-installer step: docker inspect 307b0e394010 returned [] and Error: No such object (exit 1).

The timeline in the job log shows what happened. The lock-change step logged success at 14:03:28.54. The failure diagnostics then ran at 14:03:28.80. So the failure came from the first waitFor poll after the step started hack up --json in the background with a new install command and a new hack.dependencies.cache-generation label.

The poll calls ownedContainers, which runs docker ps -aq and then docker inspect as two separate calls. The ID it listed was the linked worktree's exited install container from the lock-change step. The concurrent hack up changed that service's configuration, so Compose removed the container and created a new one between the two calls. The strict checkedDocker inspect then failed the scenario. The diagnostics that followed show a fresh linked install container with exit 0 and no logs, which is the new container Compose had just created.

The problem was in the test helper's list-then-inspect step. The dependency-cache behavior itself was not at fault.

Fix

tests/e2e/scenarios/pattern-fixture.ts:

• A new pure function, partitionContainerInspection, splits a docker inspect --type container <listed ids> result into the inspected containers and the listed IDs that no longer exist. It accepts a missing ID only when all of these hold:

  • stdout is a JSON array;
  • every stderr line is a No such object or No such container line for an ID it listed (the wording differs between client versions);
  • each listed ID is either inspected or reported missing, never both and never neither;
  • the exit code matches: 0 only when no ID is missing.

  Any other result is an error: a timeout, output that is not JSON, a daemon or permission error, a missing ID it did not list, or an ID that is silently dropped.

• ownedContainers inspects with --type container. For each missing ID, it runs docker ps -aq --filter id=<id> to confirm the container is really gone, then leaves it out of the result and logs that it did so. Any other inspection failure still fails the scenario.

What stays guaranteed

The scenario's assertions are unchanged. The killed attempt's volume must still be populated but have no ready marker. No running consumer may mount it. A retry of the same generation must still be refused and must address the same volume. A generation bump must still recover with a fresh payload. only() still requires exactly one owned container, and the waitFor poll retries until the running installer has started writing.

Tests

• tests/e2e/pattern-fixture.test.ts (new) covers:

  • the exact CI failure shape;
  • partial removal, with both stderr wordings;
  • eight rejection cases (daemon error, an ID that was not listed, an extra stderr line, an ID that is silently dropped, an ID that is both inspected and reported missing, exit 0 with a missing ID, a timeout, output that is not an array).

• Each test was checked by mutating the code under test:

  Mutation	Result
  Restore "any non-zero exit fails"	2 tests fail
  Accept any stderr line	rejection test fails
  Drop the exit/missing agreement check	rejection test fails
  Drop the inspected-or-reported check	rejection test fails

Evidence

• Bun 1.4.2 (mise x bun@1.4.2). Docker client and server 29.8.2 (OrbStack, arm64).
• Real-engine reproduction of the race. A docker shim on PATH removed one of two owned test containers just before docker inspect, then the real ownedContainers ran against the real daemon:
  • Old helper (next): fails with docker inspect pattern fixture operation (expected exit 0, got 1). This is the CI error.
  • Fixed helper: returns the surviving container and logs owned container(s) <id> were removed between listing and inspection; confirmed absent.
  • Cleanup: zero leftover owned containers.
• The real client's stderr for a missing ID is Error response from daemon: No such container: <id> with --type container, and error: no such object: <id> without it. The tests cover both.
• bun run --cwd packages/cli typecheck: clean. bun run --cwd packages/cli check: 0 errors (34 existing warnings). gitleaks 8.30.1 over the branch: no leaks.
• Full bun run test on a heavily loaded shared host (load average 40–145) had 795 failures across 119 files.
  • On a serial rerun with --timeout 60000, 104 of those 119 files passed.
  • 15 native-compose and native-authored files still fail. They do not import the changed module. Only the e2e scenarios and the new unit test import tests/e2e/scenarios/pattern-fixture.ts.
  • The pattern-fixture and pattern-examples tests pass.

Remaining gaps

• I could not run the full P01 scenario locally. The run passed the cold and warm steps, then the linked-worktree hack up failed with all predefined address pools have been fully subnetted. The local daemon's networks belong to other projects and agents, and I did not prune any of them. Hosted docker-e2e shard 3 on this head is the end-to-end proof that is still needed.
• The 15 local unit-test files that still fail need hosted CI on this head to confirm they are unrelated.

Refs HACK-1296

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[linear-code]

HACK-1296