Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2uprnlv3zi is past its budget: trevato/forge: "the releases page > a writer gets a button on a kept release, not on the live or a pruned one" failed o… #4667
Check · Review · Land · Live done — Landed and live in production.
This makes the "a writer gets a button on a kept release…" test in `test/releases-page.test.ts` independent of machine load. I'm inferring the cause rather than having seen it fail. The test passes here in under a second, and I had no failing log to work from.
shipped production is serving it deploy c82665e
This makes the "a writer gets a button on a kept release…" test in test/releases-page.test.ts independent of machine load. I'm inferring the cause rather than having seen it fail. The test passes here in under a second, and I had no failing log to work from.
The likely cause is a timeout. That test signed in on its own, and the password hash is the slow step on a loaded check machine. It also made /releases import a fixture schema file holding a 10,000-entry array. Either could push a test past Bun's 5 s default timeout.
- Sign-in: alice now signs in once in
beforeAll, with a 60 s timeout, and the test reuses that cookie. - Fixture: the fake kept release's schema now has
migrations.length + 1entries instead of 10,000. That is still ahead of the live schema, so the button still shows.
All 8 tests in the file pass and tsc --noEmit is clean. I didn't run the whole check; the forge runs that on push.
I left the other tests in the file signing in on their own, since they aren't the flaky one. Moving them to cached cookies would be a follow-up if they start timing out too.
Test-only change, and it holds up. The test file passes here (8/8). migrations is exported from src/core/schema.ts, and migrations.length + 1 still puts the kept release ahead of the live schema, so the rollback button still shows. The single sign-in in beforeAll has a 60 s timeout, and it removes the slow password hash from the flaky test. This touches no product code, security or doors. The cause is inferred rather than seen in a failing log, as the author says.
Two things I would do next:
- Move the other tests in this file onto the cached cookie too, if they start timing out.
- Add a short comment on the fixture line saying why the array is
migrations.length + 1.
This makes the "a writer gets a button on a kept release…" test in
test/releases-page.test.tsindependent of machine load. I'm inferring the cause rather than having seen it fail. The test passes here in under a second, and I had no failing log to work from.The likely cause is a timeout. That test signed in on its own, and the password hash is the slow step on a loaded check machine. It also made
/releasesimport a fixture schema file holding a 10,000-entry array. Either could push a test past Bun's 5 s default timeout.beforeAll, with a 60 s timeout, and the test reuses that cookie.migrations.length + 1entries instead of 10,000. That is still ahead of the live schema, so the button still shows.All 8 tests in the file pass and
tsc --noEmitis clean. I didn't run the whole check; the forge runs that on push.I left the other tests in the file signing in on their own, since they aren't the flaky one. Moving them to cached cookies would be a follow-up if they start timing out too.
Closes #4661