Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:360aaruftp was degraded 60 minutes today: trevato/forge: "the terminal lays out for the terminal it is in > under the floor, one line says what would help" faile… #3079
Check · Review · Land · Live done — Landed and live in production.
I gave the flaky terminal-floor test a 60-second limit. I haven't confirmed that the default 5-second limit was what failed on the check machine, so the flakiness may not be fixed. `test/tui-size.test.ts` passes locally (18 tests), but it also passed before the change, so that run says nothing about the fix.
shipped production is serving it deploy d5b2fe2
I gave the flaky terminal-floor test a 60-second limit. I haven't confirmed that the default 5-second limit was what failed on the check machine, so the flakiness may not be fixed. test/tui-size.test.ts passes locally (18 tests), but it also passed before the change, so that run says nothing about the fix.
What changed: the test "under the floor, one line says what would help" in test/tui-size.test.ts now has a 60-second limit, held in a named constant TEST_TIMEOUT_MS. Before, it ran under bun's default 5 seconds. The test boots a real forge and resizes through five sizes, waiting for the app to settle each time. On a loaded check machine, those waits can add up to more than 5 seconds. I read that as the cause from the test's shape and from the earlier sentinel fix #3065, which handled the same kind of flake. I did not reproduce the failure.
What I left alone: the test's assertions and the app code are unchanged. A real hang still fails sooner, because each resize waits at most FRAME_WAIT_MS (10 seconds) and then names the size it was waiting for.
What I left out: I did not shrink the test or give it a lighter setup. The resize sequence and the real-forge boot are what the test is for.
To try it: run bun test test/tui-size.test.ts. The sentinel's check, that the cause stays out of the degraded list for a day, needs the forge's own checks over the next day to confirm.
Test-only change: the one test that boots a real forge and resizes through five sizes gets a 60s limit in a named constant, with a comment saying why. No app code, no security surface, no page or terminal behaviour touched, so the preview has nothing to show here. The assertions are unchanged, and a real hang still fails at FRAME_WAIT_MS (10s) naming the size. The test does boot plus five awaited resizes, so the default 5s limit being the cause is plausible, and the author is honest that it was not reproduced.
Two things I would do next: (1) if the sentinel still lists this test in a day, log the elapsed time per resize in the failure message so the next flake shows which step was slow instead of guessing; (2) check whether the other tests in this file that boot a forge are close to the 5s default too, and give them the same constant before they become the next sentinel entry.
I gave the flaky terminal-floor test a 60-second limit. I haven't confirmed that the default 5-second limit was what failed on the check machine, so the flakiness may not be fixed.
test/tui-size.test.tspasses locally (18 tests), but it also passed before the change, so that run says nothing about the fix.What changed: the test "under the floor, one line says what would help" in
test/tui-size.test.tsnow has a 60-second limit, held in a named constantTEST_TIMEOUT_MS. Before, it ran under bun's default 5 seconds. The test boots a real forge and resizes through five sizes, waiting for the app to settle each time. On a loaded check machine, those waits can add up to more than 5 seconds. I read that as the cause from the test's shape and from the earlier sentinel fix #3065, which handled the same kind of flake. I did not reproduce the failure.What I left alone: the test's assertions and the app code are unchanged. A real hang still fails sooner, because each resize waits at most
FRAME_WAIT_MS(10 seconds) and then names the size it was waiting for.What I left out: I did not shrink the test or give it a lighter setup. The resize sequence and the real-forge boot are what the test is for.
To try it: run
bun test test/tui-size.test.ts. The sentinel's check, that the cause stays out of the degraded list for a day, needs the forge's own checks over the next day to confirm.Closes #3074