Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:h503k9k7s7 was degraded 26 minutes today: trevato/forge: "apps, runs and the crew on the web > the runs list, one run's log page, and the short door to it" faile… #3034
Check · Review · Land · Live done — Landed and live in production.
This pull widens the timeouts in one test so a loaded check machine no longer fails it. I could not reproduce the failure locally, so the cause is inferred, not confirmed.
shipped production is serving it deploy c523fde
This pull widens the timeouts in one test so a loaded check machine no longer fails it. I could not reproduce the failure locally, so the cause is inferred, not confirmed.
The test is "the runs list, one run's log page, and the short door to it" in test/web-apps.test.ts. The earlier hardening (#3006) had already made it wait for the deploy to settle. Three fixed waits were still tight for a loaded lane:
- First run to appear: waited 10 s, now 30 s.
- Run state to hold steady across a render: waited 5 s, now 15 s.
- Deploy to settle: waited 20 s, now 60 s.
- Whole-test timeout: was 40 s, now 120 s, which has to cover the longer waits.
The assertions are unchanged, so the test still fails on a real hang. It does so later.
The whole web-apps file passed three times in a row before the change and once after. I did not get a tsc result: bun x tsc --noEmit stopped with "bun is unable to write files to tempdir".
I did not touch the deploy runtime's speed. If this test is still red under load after this, the next step is to look at why a deploy takes that long on the check machine.
Test-only change: widens three waits and the whole-test timeout in one test. The helper takes the timeout argument, assertions are unchanged, and the worst-case waits (30+15+60 s) fit under the new 120 s bound. No security, door or direction impact. Two things I would do next: (1) find out why a deploy takes this long on the check lane instead of only raising bounds, since the cause is still inferred; (2) pull the repeated wait-for-settle loops in this file into one helper so the bounds live in one place.
This pull widens the timeouts in one test so a loaded check machine no longer fails it. I could not reproduce the failure locally, so the cause is inferred, not confirmed.
The test is "the runs list, one run's log page, and the short door to it" in
test/web-apps.test.ts. The earlier hardening (#3006) had already made it wait for the deploy to settle. Three fixed waits were still tight for a loaded lane:The assertions are unchanged, so the test still fails on a real hang. It does so later.
The whole
web-appsfile passed three times in a row before the change and once after. I did not get atscresult:bun x tsc --noEmitstopped with "bun is unable to write files to tempdir".I did not touch the deploy runtime's speed. If this test is still red under load after this, the next step is to look at why a deploy takes that long on the check machine.
Closes #3031