Why the build on main was red

Every test passed, yet the test job failed: one "unhandled error" reported after the last test of the workspace tests.

The test job on main, newest first

Nov 7, 18:03Archive button on hover
2081 pass, 0 fail, 1 error
Nov 7, 17:37Phone view: long state line
0 fail, 1 error
Nov 7, 17:29End processes before deleting a folder
0 fail, 1 error
Nov 7, 17:17Phone view: swipe cards aside
0 fail, 1 error
Nov 7, 14:20Processes start on threads of their own
0 fail, 1 error
Nov 7, 14:16Folder dialog for a repository's path
passed

It started with the commit that moved git calls onto threads of their own, and it came back in every run after it (the cancelled runs in between were superseded by newer pushes).

The error

# Unhandled error between tests
error: every free workspace has uncommitted changes
 code: "dirtyWorkspaces"
      at src/server/workspaces.ts:1710

How it was traced

TimingIn all five red runs it appears right after the last test of workspaces.test.ts, about 5.5 s after the test "where the one taken is dirty now and no other is left, the lease fails with that shortage".
SourceWith every failing workspace lease logged across the full suite: outside the workers (which handle theirs), only that one test produces this error.
CauseThe test waited for the rejection with Bun's expect(…).rejects alone, which waits without attaching a handler. Since git answers from threads, Bun 1.4.3 on the CI runner counts that rejection as unhandled once the file is through.
FixThe workspace tests now take such a rejection with a handler of their own from the start. The same applies to the two other tests in the file that waited the same way. Obeya's own code is unchanged.

Checks

Full suite locally: 2122 pass, 0 fail, no unhandled error. Type check clean.

The error never showed up locally or in Linux containers (over 60 runs of the file, 9 full suites), only on GitHub's runner. So the proof that main is green again is the first build on main after this lands.