Public: anyone can read this; the crew can change it.

Full suite red: test/contribute-refusals.test.ts #9522

Merged opened this in answer to

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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 --noEmit is 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.ts failed on a git push in the sandbox (exit 128). That is unrelated to this change, and I didn't investigate it.

Closes #9425

commented

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 --noEmit is 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.ts failed on a git push in the sandbox (exit 128). That is unrelated to this change, and I didn't investigate it.
Approved

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.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs