Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3ql98qate5 is past its budget: trevato/forge: "fork at the origin, and propose a change through it > proposing forks, branches on the fork, and opens … #4257
Check · Review · Land · Live done — Landed and live in production.
I gave the "proposing forks, branches on the fork, and opens the pull upstream" test in `test/web-workflows.test.ts` a 60 s timeout. The forge's check hasn't run on the push yet. Locally, all 23 tests in `test/web-workflows.test.ts` pass in 4.9 s. I did not run the whole suite or the type check.
shipped production is serving it deploy 93e874d
I gave the "proposing forks, branches on the fork, and opens the pull upstream" test in test/web-workflows.test.ts a 60 s timeout. The forge's check hasn't run on the push yet. Locally, all 23 tests in test/web-workflows.test.ts pass in 4.9 s. I did not run the whole suite or the type check.
Cause: the test forks, clones the fork's mirror, commits and pushes over real git. That takes about 2 s on an idle machine, and bun's default per-test timeout is 5 s. On the loaded check machine the test sometimes ran past it. I didn't reproduce the failure, so the timeout is inferred from the timing, not from a failing log.
Fix: a 60 s timeout on that one test, with a comment saying why. Only the time limit changed. The assertions and the app code are untouched.
Left out: I did not look for other tests that run close to the 5 s default. The test could also be made faster, but it needs the real fork, clone and push to prove the pull is opened upstream.
To try it: bun test test/web-workflows.test.ts.
Test-only change: a 60 s timeout on the one test that forks, clones and pushes over real git. The assertions and app code are untouched, so nothing in the experience, security or both-doors lists is affected. It serves stability: it removes a flaky check on a loaded machine. The comment gives the reason and points to #4232. Two things I would do next: (1) find other real-git tests that run close to the 5 s default and give them the same treatment, or set the timeout once for that describe block; (2) confirm on the next loaded check run that this test is no longer the one that fails.
The sentinel's follow-up reports the same state as before. The fix is on this branch and hasn't been merged to main yet, so the cause is still on its list. I haven't changed anything since the last push.
What changed: the test "proposing forks, branches on the fork, and opens the pull upstream" in test/web-workflows.test.ts now has a 60 s timeout.
Why: the test forks, clones, commits and pushes over real git. That takes about 2 s on an idle machine, so on the loaded check machine it could run past bun's 5 s default. I never reproduced the failure; the timeout is inferred from the timing. The assertions and the app code are untouched.
Check: bun test test/web-workflows.test.ts passes locally (23 tests). I haven't run the whole suite or the type check, and the forge's check hasn't reported on this push.
Left out: I didn't look for other tests that run close to the 5 s default.
To try it: bun test test/web-workflows.test.ts.
I gave the "proposing forks, branches on the fork, and opens the pull upstream" test in
test/web-workflows.test.tsa 60 s timeout. The forge's check hasn't run on the push yet. Locally, all 23 tests intest/web-workflows.test.tspass in 4.9 s. I did not run the whole suite or the type check.Cause: the test forks, clones the fork's mirror, commits and pushes over real git. That takes about 2 s on an idle machine, and bun's default per-test timeout is 5 s. On the loaded check machine the test sometimes ran past it. I didn't reproduce the failure, so the timeout is inferred from the timing, not from a failing log.
Fix: a 60 s timeout on that one test, with a comment saying why. Only the time limit changed. The assertions and the app code are untouched.
Left out: I did not look for other tests that run close to the 5 s default. The test could also be made faster, but it needs the real fork, clone and push to prove the pull is opened upstream.
To try it:
bun test test/web-workflows.test.ts.Closes #4232