script/cibuild on a fresh clone of next (aeb275e) failed while this host was under its usual load (a load average of 100 to 150 on 48 cores). In test/cli/bin.test.ts, the first test, "loads the session for backup with the unattended retry options", ran past vitest's 5-second test timeout in both the dot run and the verbose rerun. Its import of bin/quak.ts then finished late and added to the shared loaded array, so the next test, "loads the session for another command with the default retry options", failed with two entries. A rerun passed, with that file taking 4.2 seconds for its four tests. main has the same file, which took 5.1 seconds in one run. next and main must pass on this host under its usual load, so this is a bug on both.
Two causes:
vitest starts one worker per CPU core, 48 here (Docker shows the container every core). vitest.config.ts sets no limit. Standing rule: the repo's test entrypoint caps its workers.
Each test in test/cli/bin.test.ts calls vi.resetModules() and imports bin/quak.ts and everything it imports again. The first import loads it all from cold, which under load takes more than 5 seconds.
Definition of done
vitest.config.ts sets maxWorkers to a small fixed number: the smallest that keeps the whole suite well inside the Dockerfile's existing timeout 90 on this host. The PR body says the number and why.
test/cli/bin.test.ts no longer pays for the slow part of loading bin/quak.ts inside each timed test. Find which import is slow, then either load it once before the tests run or mock it where the tests do not need it. Raising a timeout is not a fix: not vitest's testTimeout, not a per-test timeout, not the Dockerfile's timeout 90.
With the limit in place, any other test that still takes more than about half of its 5-second timeout under load is fixed the same way.
Files: vitest.config.ts and test/cli/bin.test.ts, plus any other test file the previous point reaches, and the TODO.md entry. No product code changes.
script/cibuild passes on a fresh clone, three runs in a row, with the host under its usual load. Run each under the shared lock, so that this unit's worker and reviewer never run the check at the same time: flock -w 900 /srv/code/tmp/.quak-check.lock script/cibuild. flock -w exits 1 without running the command when it times out, which looks the same as a failed check, so wait and run it again. Post no logs or timings.
PR into next; the landing commit title ends (closes #N), with this issue's number.
Model: opus-5-5
`script/cibuild` on a fresh clone of `next` (`aeb275e`) failed while this host was under its usual load (a load average of 100 to 150 on 48 cores). In `test/cli/bin.test.ts`, the first test, "loads the session for backup with the unattended retry options", ran past vitest's 5-second test timeout in both the dot run and the verbose rerun. Its import of `bin/quak.ts` then finished late and added to the shared `loaded` array, so the next test, "loads the session for another command with the default retry options", failed with two entries. A rerun passed, with that file taking 4.2 seconds for its four tests. `main` has the same file, which took 5.1 seconds in one run. `next` and `main` must pass on this host under its usual load, so this is a bug on both.
Two causes:
- vitest starts one worker per CPU core, 48 here (Docker shows the container every core). `vitest.config.ts` sets no limit. Standing rule: the repo's test entrypoint caps its workers.
- Each test in `test/cli/bin.test.ts` calls `vi.resetModules()` and imports `bin/quak.ts` and everything it imports again. The first import loads it all from cold, which under load takes more than 5 seconds.
**Definition of done**
- `vitest.config.ts` sets `maxWorkers` to a small fixed number: the smallest that keeps the whole suite well inside the Dockerfile's existing `timeout 90` on this host. The PR body says the number and why.
- `test/cli/bin.test.ts` no longer pays for the slow part of loading `bin/quak.ts` inside each timed test. Find which import is slow, then either load it once before the tests run or mock it where the tests do not need it. Raising a timeout is not a fix: not vitest's `testTimeout`, not a per-test timeout, not the Dockerfile's `timeout 90`.
- With the limit in place, any other test that still takes more than about half of its 5-second timeout under load is fixed the same way.
- Files: `vitest.config.ts` and `test/cli/bin.test.ts`, plus any other test file the previous point reaches, and the `TODO.md` entry. No product code changes.
- `script/cibuild` passes on a fresh clone, three runs in a row, with the host under its usual load. Run each under the shared lock, so that this unit's worker and reviewer never run the check at the same time: `flock -w 900 /srv/code/tmp/.quak-check.lock script/cibuild`. `flock -w` exits 1 without running the command when it times out, which looks the same as a failed check, so wait and run it again. Post no logs or timings.
PR into `next`; the landing commit title ends ` (closes #N)`, with this issue's number.
Model: opus-5-5
clawbot
self-assigned this 2026-11-10 21:19:06 +01:00
Built in #234 (branch issue-233-test-load-timeouts):
vitest.config.ts caps vitest at 4 workers. It also sets minWorkers: 1, since vitest 2 rejects maxWorkers alone.
test/cli/bin.test.ts compiles the sources bin/quak.ts imports and starts libsodium at the top of the file, before any test runs.
The thumbnail tests and the metadata-backup "is incremental" test were the other ones over half their timeout. Their fake accounts now use libsodium's lowest Argon2id cost, since each login runs the KDF again.
No product code changed.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/quak/pulls/234 (branch `issue-233-test-load-timeouts`):
- `vitest.config.ts` caps vitest at 4 workers. It also sets `minWorkers: 1`, since vitest 2 rejects `maxWorkers` alone.
- `test/cli/bin.test.ts` compiles the sources `bin/quak.ts` imports and starts libsodium at the top of the file, before any test runs.
- The thumbnail tests and the metadata-backup "is incremental" test were the other ones over half their timeout. Their fake accounts now use libsodium's lowest Argon2id cost, since each login runs the KDF again.
No product code changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
script/cibuildon a fresh clone ofnext(aeb275e) failed while this host was under its usual load (a load average of 100 to 150 on 48 cores). Intest/cli/bin.test.ts, the first test, "loads the session for backup with the unattended retry options", ran past vitest's 5-second test timeout in both the dot run and the verbose rerun. Its import ofbin/quak.tsthen finished late and added to the sharedloadedarray, so the next test, "loads the session for another command with the default retry options", failed with two entries. A rerun passed, with that file taking 4.2 seconds for its four tests.mainhas the same file, which took 5.1 seconds in one run.nextandmainmust pass on this host under its usual load, so this is a bug on both.Two causes:
vitest.config.tssets no limit. Standing rule: the repo's test entrypoint caps its workers.test/cli/bin.test.tscallsvi.resetModules()and importsbin/quak.tsand everything it imports again. The first import loads it all from cold, which under load takes more than 5 seconds.Definition of done
vitest.config.tssetsmaxWorkersto a small fixed number: the smallest that keeps the whole suite well inside the Dockerfile's existingtimeout 90on this host. The PR body says the number and why.test/cli/bin.test.tsno longer pays for the slow part of loadingbin/quak.tsinside each timed test. Find which import is slow, then either load it once before the tests run or mock it where the tests do not need it. Raising a timeout is not a fix: not vitest'stestTimeout, not a per-test timeout, not the Dockerfile'stimeout 90.vitest.config.tsandtest/cli/bin.test.ts, plus any other test file the previous point reaches, and theTODO.mdentry. No product code changes.script/cibuildpasses on a fresh clone, three runs in a row, with the host under its usual load. Run each under the shared lock, so that this unit's worker and reviewer never run the check at the same time:flock -w 900 /srv/code/tmp/.quak-check.lock script/cibuild.flock -wexits 1 without running the command when it times out, which looks the same as a failed check, so wait and run it again. Post no logs or timings.PR into
next; the landing commit title ends(closes #N), with this issue's number.Model: opus-5-5
Built in #234 (branch
issue-233-test-load-timeouts):vitest.config.tscaps vitest at 4 workers. It also setsminWorkers: 1, since vitest 2 rejectsmaxWorkersalone.test/cli/bin.test.tscompiles the sourcesbin/quak.tsimports and starts libsodium at the top of the file, before any test runs.No product code changed.
Model: opus-5-5