fix(test): widen more subprocess/eventual-consistency timeouts causing flaky unit failures - #202
Closed
alltomatos wants to merge 5 commits into
Closed
alltomatos wants to merge 5 commits into
alltomatos wants to merge 5 commits into
Conversation
…g flaky unit failures Same class of issue as #191, recurring with a different set of tests under CI load: - run-process.test.ts: "--format json emits a pure error record for a rejected prompt request" (30s->60s) — outer bound was tighter than the harness's own 60s subprocess timeout default (test/lib/cli-process.ts), so CI-load variance tripped the test timeout before the subprocess itself could time out. Observed 30060ms on 2026-09-12. - prompt.test.ts: "loop waits while shell runs and starts after shell exits" (10s->30s) — cold-start variance on a spawned "sleep 0.2" child process could push this past a 10s bound; other subprocess instance tests in this file already use 30s. Observed 10000.96ms. - workspace.test.ts: eventuallyEffect default poll timeout (1500ms->5000ms) — workspace sync status transitions (e.g. detecting a missing target directory) can take longer than 1.5s to propagate under CI load. Observed a 16875ms failure on 2026-09-12. All widened with headroom rather than shaved to the exact observed miss, so a genuine hang still fails loudly. Verified: all three tests pass individually, and the full workspace/prompt/run-process suites (108 tests) pass together. Co-Authored-By: Claude Sonnet 5 <[email protected]>
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
3 of 6 tasks
3 of 6 tasks
Resolves conflicts in run-process.test.ts, workspace.test.ts, and prompt.test.ts: dev already landed an equivalent/superset fix for the same timeout issue via #163 (explicitly "port fix from #202") and a follow-up prompt.test.ts timeout widen — kept dev's versions since they're functionally identical or better (same 60s/30s/5000ms values, plus dev's own additional widened prompt-shell-loop timeouts). Co-Authored-By: Claude Sonnet 5 <[email protected]>
Owner
Author
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.
Issue for this PR
Closes #163
Type of change
What does this PR do?
Same class of issue as #163 / #162 (widened subprocess timeouts to match CI-load cold-start headroom), recurring with three different tests, confirmed by inspecting recent
testworkflow failures ondevand other branches viagh run view --log-failed:run-process.test.ts:--format json emits a pure error record for a rejected prompt requestouter bound was 30s, tighter than the harness's own 60s subprocess timeout default (test/lib/cli-process.ts) — bumped to 60s. Observed a 30060ms failure on 2026-09-12.prompt.test.ts:loop waits while shell runs and starts after shell exitsbound was 10s; cold-start variance on a spawnedsleep 0.2child process pushed it past that under CI load — bumped to 30s, matching sibling subprocess-spawning tests in the same file. Observed 10000.96ms.workspace.test.ts: the localeventuallyEffectpoll helper's default timeout was 1500ms; workspace sync status transitions (e.g. detecting a missing target directory) can take longer to propagate under CI load — bumped default to 5000ms. Observed a 16875ms failure.All three bumps add headroom rather than shave to the exact observed miss, so a genuine hang still fails loudly. The global
bun test --timeout 60000bound is unaffected and still bounds worst case.Also confirmed the "tui plugin timed out cleaning up" lines that show up in nearly every CI log are just a runtime warning (
src/plugin/tui/runtime.ts), not a test failure — no change needed there.How did you verify your code works?
bun test test/cli/run/run-process.test.ts -t "emits a pure error record"— passbun test test/session/prompt.test.ts -t "loop waits while shell runs and starts after shell exits"— passbun test test/control-plane/workspace.test.ts -t "reports error when the target directory is missing"— passbun turbo typecheck— all 30 packages pass (ran automatically on push via hook)Screenshots / recordings
N/A (test-only change, no UI impact).
Checklist
🤖 Generated with Claude Code