(test): run trigger-watcher timing tests serially with a load tolerance - #261
Merged
Merged
Conversation
npm test now runs trigger-watcher.test.js alone, after everything else, removing the self-contention of ~150 sibling test-file processes. A few tight bounds (a ceiling, two upper-bound elapsed checks, a shared auto-turn schedule) were widened so real host load no longer flakes them; lower bounds proving ordering/minimum-wait are untouched.
…t to the file entry
This was referenced Sep 11, 2026
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #260.
Why
test/trigger-watcher.test.jsdrives real timers and realfs.watchagainst fixed wall-clock budgets. Under host load it fails on a changing subset of 5–7 tests unrelated to the change being committed; on 2026-09-11 the pre-commit hook was red 5 times out of 7 on this workstation for that reason alone. Part of that load is self-inflicted:node --testruns ~150 test files in parallel, and the timing tests compete with the other workers of the same run.What
scripts/run-tests.jsruns the suite in two stages: every file except the trigger-watcher one with node's default concurrency, then that file alone with--test-concurrency=1 --test-timeout=60000.npm testandnpm run coverageroute through it (cross-platform, no shell syntax; c8 still instruments the children through the inherited env).SWITCHBOARD_TEST_TIME_SCALE(default 1) scales only the upper-bound assertions and thewaitForFileceiling in that file; lower bounds that prove an ordering or a minimum wait are untouched. Three fragile schedules were widened unconditionally (shared chain busy plateau 150 → 550 ms,W7schedule, the settle-window test constants doubled) — the wrong-vs-right margins are preserved..ai/contexts/trigger-watcher.md, with what a real clock injection would take (the five wall-clock-owning functions, ~20 exact-value tests); left as a follow-up.Proof
Reproduced first under a synthetic load of 8 CPU-saturating processes on this 8-core machine: 6 tests red (timeouts waiting for the result file, missed busy-rise,
waited_msfloors). After: 3 consecutive runs under the same load, 119/119. Mutation: removing theidleSincereset inwaitForBusyFallstill makes the settle-window test red under the widened bounds.task checkin the worktree: main stage 1144 pass, isolated stage 119 pass, 0 fail, 8 pre-existing skips; the commit's own pre-commit hook passed.