fix(compass-agent): give the config-passthrough afterEach cleanup a real timeout (RIG-3609) - #1064
Open
rigel-mintaka wants to merge 2 commits into
Open
fix(compass-agent): give the config-passthrough afterEach cleanup a real timeout (RIG-3609)#1064rigel-mintaka wants to merge 2 commits into
rigel-mintaka wants to merge 2 commits into
Conversation
…eal timeout (RIG-3609) `cli.config-passthrough.test.ts`'s shared `afterEach` recursively `rmSync`s the accumulated deep `/tmp` mount fixtures with no explicit hook timeout, so it runs under bun's 5s default. Under the jj pre-push gate — worktree also in `/tmp`, bun running `2x` parallel — that recursive delete outruns 5s and the hook times out (`a beforeEach/afterEach hook timed out` at 12.9s and 15.4s), reddening the gate on a test whose assertions all pass. Isolated the file is 23/0 in ~2.7s. Give the hook an explicit generous `30_000` ms bound, matching the convention the `(g)` subprocess test in this same file already uses and documents (bun does not treat a lifecycle-hook file's `0` as "no timeout" — it silently falls back to 5s, so an explicit bound is the only way to raise the ceiling). This is a crash-guard bound, not a timing budget: the cleanup is legitimate recursive FS I/O whose duration is dominated by external parallel-load contention, not flaky logic, so this is not a masked retry. Reported-by compass-forge (its pre-push gate). Closes RIG-3609 Co-authored-by: Matt Wilkinson <matt@rigel.build>
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
Compass engineering docs preview: https://compass-agent-rig-3609-passt.compass-eng-docs.pages.dev Deployed from |
…ment (RIG-3609) Review R1 lows: (1) "crash-guard" overstated it — bun cannot preempt the synchronous rmSync, so the bound is a slow-cleanup detector, not a true crash guard (unlike (g)'s awaited Bun.spawn). (2) 30s headroom was ~1.95x the 15.4s worst case, thinner than "generous" implied, with /tmp at 91% on this box. Bumped to 60_000 (~4x worst case) and reworded the comment accordingly. The sibling-files finding (four other test files carry the same unbounded hook) is filed as RIG-3611, scoped out of this PR. Co-authored-by: Matt Wilkinson <matt@rigel.build>
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.
cli.config-passthrough.test.ts's sharedafterEachrecursivelyrmSyncs the accumulated deep/tmpmount fixtures with no explicit hook timeout, so it runs under bun's 5s default. Under the jj pre-push gate — worktree also in/tmp, bun running2xparallel — that recursive delete outruns 5s and the hook times out (a beforeEach/afterEach hook timed outat 12.9s and 15.4s), reddening the gate on a test whose assertions all pass. Isolated the file is 23/0 in ~2.7s.Give the hook an explicit generous
30_000ms bound, matching the convention the(g)subprocess test in this same file already uses and documents (bun does not treat a lifecycle-hook file's0as "no timeout" — it silently falls back to 5s, so an explicit bound is the only way to raise the ceiling). This is a crash-guard bound, not a timing budget: the cleanup is legitimate recursive FS I/O whose duration is dominated by external parallel-load contention, not flaky logic, so this is not a masked retry.Reported-by compass-forge (its pre-push gate).
Closes RIG-3609
Co-authored-by: Matt Wilkinson matt@rigel.build