Summary

runScheduledCleanup > continues processing after error on one environment in packages/core/src/services/cleanup-service.test.ts fails on the dev branch, blocking CI for any PR that merges dev.

Reproduction

Pristine clone of origin/dev (commit c4ab0a23):

git fetch origin dev
git worktree add /tmp/archon-dev origin/dev
cd /tmp/archon-dev && bun install
bun test packages/core/src/services/cleanup-service.test.ts

Output:

(fail) runScheduledCleanup > continues processing after error on one environment [2.40ms]
 41 pass
 1 fail

Assertion that fails

cleanup-service.test.ts:720:

expect(report.removed).toContain('env-error (path missing)');

Received: [] (empty array).

The test sets up two active environments with mockExecFileAsync rejecting ('not a git repo') for both worktreeExists calls, then expects both envs to land in report.removed as (path missing).

Likely cause

PR #1034 (fix(isolation): complete reports false success when worktree remains on disk, merged 2026-04-14) added:

• git worktree prune in WorktreeProvider.destroy()
• Post-removal verification via git worktree list --porcelain

These changes cascade into runScheduledCleanup via removeEnvironment() — the test's mocked execFileAsync rejections likely now bubble up through a path that previously caught-and-skipped. Either the cleanup service needs an extra try/catch around removeEnvironment, or the test needs additional mockExecFileAsync mocks to satisfy the new verification step.

Not 100% confirmed to be #1034 — that's the timing and area match, not a traced diff.

Impact

• Every PR branched off dev hits the same CI failure regardless of its own changes
• Dev's own CI runs are failing (see run 24439449385 — type-check failure there is separate; test failure is in preceding runs like 24406310125)
• Currently hitting it on feat: add optional submodule initialization for worktrees #1189 (submodule init PR), presumably others too

Scope suggestion

Either:

1. Fix the test to satisfy the new destroy-path verification (additional exec mocks), or
2. Fix the cleanup-service behavior so a removeEnvironment error on one env doesn't silently drop it from report.removed (the test's stated intent — "continues processing after error")

Option 2 matches the test name's semantic better. An env whose verification exec fails should still appear in report.errors or similar, so callers learn about it.

Related

• fix(isolation): complete reports false success when worktree remains on disk (fixes #964) #1034 — most recent change to this path
• bug(isolation): archon complete reports success but leaves git worktree on disk #964 — the original bug that fix(isolation): complete reports false success when worktree remains on disk (fixes #964) #1034 fixed