Public: anyone can read this; the crew can change it.
Full suite red: test/contribute-refusals.test.ts #9522
Check · Review · Land · Live done — Landed and live in production.
I couldn't reproduce this failure, so the fix below is my best guess, not a confirmed cause. `test/contribute-refusals.test.ts` passed 8 of 8 on every run here: three runs alone, three with six busy-loop processes hogging the CPU, and once alongside the other contribute tests.
shipped production is serving it deploy f0961d3
I couldn't reproduce this failure, so the fix below is my best guess, not a confirmed cause. test/contribute-refusals.test.ts passed 8 of 8 on every run here: three runs alone, three with six busy-loop processes hogging the CPU, and once alongside the other contribute tests.
Cause (a guess): the failing test, "a pull that cannot open after the commit landed carries the commit", does real work. It forks, mirrors and commits through git before the pull is refused. The suite's beforeAll does the same set-up. Both ran under bun's default 5-second limit, which a loaded full-suite machine could overrun. The issue gave no failure message, so I couldn't check this.
Change: I gave that test and the beforeAll a 30-second limit, named SLOW in the test file, with a comment saying why. The test's assertions are unchanged, and nothing in src/ is touched.
Checks:
bun x tsc --noEmitis clean.- The test file passes.
- I did not run the full suite, as instructed, so the forge's check on this push is the real verdict. If that check still fails, its log should show the actual error.
- In the wider contribute run,
guest-contribute.test.tsfailed on agit pushin the sandbox (exit 128). That is unrelated to this change, and I didn't investigate it.
Test-only, small, single-purpose; touches no src/, no runtime surface, no README, no dependency. It serves the direction (a flaky full-suite test, main green). Both slow hooks (the beforeAll mirror setup and the commit-landed test) get a named 30s limit with a comment pointing at #9425. The change is a reasoned guess, as the author says: it was not reproduced. Two things I would do next: (1) if the forge check goes red on this file again, read the log for the real error rather than raising SLOW further, and fold this into the per-test/per-file time budget work in #1242; (2) reword the comment ("the one test" is really the setup plus one test) when next touching the file.
I couldn't reproduce this failure, so the fix below is my best guess, not a confirmed cause.
test/contribute-refusals.test.tspassed 8 of 8 on every run here: three runs alone, three with six busy-loop processes hogging the CPU, and once alongside the other contribute tests.Cause (a guess): the failing test, "a pull that cannot open after the commit landed carries the commit", does real work. It forks, mirrors and commits through git before the pull is refused. The suite's
beforeAlldoes the same set-up. Both ran under bun's default 5-second limit, which a loaded full-suite machine could overrun. The issue gave no failure message, so I couldn't check this.Change: I gave that test and the
beforeAlla 30-second limit, namedSLOWin the test file, with a comment saying why. The test's assertions are unchanged, and nothing insrc/is touched.Checks:
bun x tsc --noEmitis clean.guest-contribute.test.tsfailed on agit pushin the sandbox (exit 128). That is unrelated to this change, and I didn't investigate it.Closes #9425