[miguel-heygen]

What

Each CLI test file now gets a home folder of its own, so per-user state such as the render lock is never shared by two test files running at the same time.

Why

render command batch options > forwards gif loop and video frame format to batch row renders has been timing out at 60 s on CI, on main and on unrelated PRs. Its own log says why:

Waiting for another render to finish (pid 3160, project /tmp/hf-studio-server-test-…, running 0s). Renders run one at a time per user account; pass --no-wait to stop instead
Lock: /tmp/hf-test-home-…/.cache/hyperframes/locks/render.lock

scripts/test-home.mjs is imported by vitest.config.ts before workers fork, so every test file in a run shares one home folder, and with it one per-user render lock. When a studioServer.test.ts render holds that lock, the batch test, in another file, waits for it like a real second render would. Whether the two overlap depends on scheduling, which is why it fails on some runs and not others.

Related work

Extends scripts/test-home.mjs (the run-wide temp home, kept as is) with a per-file home set in test.setupFiles. The lock itself (src/utils/renderLock.ts) is unchanged; tests that share a lock on purpose, such as studioServer.renderLock.test.ts, do it within one file and keep doing so.

How

• scripts/test-file-home.mjs creates a temp folder, points HOME and USERPROFILE at it, and removes it after the file's tests.
• vitest.config.ts lists it in test.setupFiles, so the unit, chrome and spawn projects all get it.

Test plan

• fails without the fix: the new src/utils/testFileHome.test.ts fails with the setup file removed from vitest.config.ts and passes with it.
• Reproduced the CI failure deterministically. A temporary test (not committed) held the run's render lock for 20 s while the batch test ran in the same vitest run, with 2 workers. Without the fix the batch test printed Waiting for another render to finish (… project /tmp/holder …) and took 17.7 s; with the fix it took 1.9 s and did not wait. A longer hold reaches the 60 s timeout seen on CI.
• The batch test alone: 5 of 5 passes, about 0.6 s each.
• Full cli test lane on a Linux machine: 8,195 passed, 9 failed in 3 files (snapshotHdrFrame, diff-offset, media). The same 9 fail with the setup file removed, so they come from that machine's ffmpeg build, not this change; CI runs them on its own ffmpeg. The batch test passed in the full run.

No visible change

Test setup only.

Size

A test-setup fix with no runtime code to ride along with: the open renderer PRs touch other packages and are red on this flake, so it goes first and alone.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 110 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

[heygengenesis]

Approving at ebc0dfc2.

• The root cause matches the evidence. scripts/test-home.mjs runs once in the config process, so every file in the run shared one HOME and one locks/render.lock. A setupFiles entry runs before each test file's own imports, so lock and cache paths that are resolved when they are used (hyperframesCacheDir) land in that file's own home. The run-wide home and its XDG/config variable clearing stay in place, and files that share a lock on purpose do it within one file.
• The "fails without the fix:" line holds; I confirmed it locally. gives each test file its own home, so files never share the per-user render lock passes on this head and fails with the setupFiles entry removed. testHome.test.ts's home assertions still pass. Its spawn case fails only in my sandbox, which has no bun on PATH, and it is green in CI.
• CI is green on this head, and the reachability hash for vitest.config.ts is updated.

Non-blocking: afterAll removes the per-file home while any detached child a file spawned may still be writing to it. That's harmless with the force: true rm, so it's only worth knowing if a cleanup ENOTEMPTY shows up later.