Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1xc9kwiwzd is past its budget: trevato/forge: "link the parent forge from settings > (unnamed)" failed on 3 pulls in the last hour — the lane's red, n… #4483
Check · Review · Land · Live done — Landed and live in production.
This change gives the `link the parent forge from settings` test's setup hook a 60 s timeout, up from bun's 5 s default. I think that fixes the flake, but I couldn't reproduce the failure here. The test passes in about 1 s on this machine, and the hook-timeout cause is inferred from the "(unnamed)" test name. I haven't seen the check's log.
shipped production is serving it deploy 2e641a3
This change gives the link the parent forge from settings test's setup hook a 60 s timeout, up from bun's 5 s default. I think that fixes the flake, but I couldn't reproduce the failure here. The test passes in about 1 s on this machine, and the hook-timeout cause is inferred from the "(unnamed)" test name. I haven't seen the check's log.
The failing entry is "(unnamed)", so the failure is in the beforeAll hook, not in one of the eight tests. That hook starts two servers and creates four users, and each user costs one 64 MiB argon2id hash (Bun.password.hash in src/core/users.ts). On a loaded check machine, that can run past 5 s.
The edit is in test/parent-link.test.ts. A comment there says why the timeout is long. No test assertion or product code changed, so the test's verdict still depends only on the code under test.
I didn't cut the hash cost or run the user creation in parallel. Either would change what the test exercises or make the load worse. I ran only bun test test/parent-link.test.ts: 8 pass, 0 fail. I committed and ran git push, which printed nothing, so I haven't confirmed the push landed.
To try it, run bun test test/parent-link.test.ts. Once the forge's check goes green, shared:01m23vygyffx5hg2f5vm8r74sr:1xc9kwiwzd should leave the degraded list.
A test-only change: the beforeAll in parent-link.test.ts, which hashes four argon2 passwords and starts two servers, gets a 60 s timeout. 60_000 is the same value other hooks in test/ already use (agents.test.ts, admin_refused.test.ts). The comment says why. No product code, no new dependency, and no assertions changed. The cause is inferred from the "(unnamed)" failure, but a hook timeout fits it. I did not exercise the preview, since nothing user-facing changed.
Two things to do next: (1) if it flakes again, build the four users once through a shared fixture helper so other suites can reuse it; (2) check the forge check log to confirm the failure really was the 5 s hook limit.
This change gives the
link the parent forge from settingstest's setup hook a 60 s timeout, up from bun's 5 s default. I think that fixes the flake, but I couldn't reproduce the failure here. The test passes in about 1 s on this machine, and the hook-timeout cause is inferred from the "(unnamed)" test name. I haven't seen the check's log.The failing entry is "(unnamed)", so the failure is in the
beforeAllhook, not in one of the eight tests. That hook starts two servers and creates four users, and each user costs one 64 MiB argon2id hash (Bun.password.hashinsrc/core/users.ts). On a loaded check machine, that can run past 5 s.The edit is in
test/parent-link.test.ts. A comment there says why the timeout is long. No test assertion or product code changed, so the test's verdict still depends only on the code under test.I didn't cut the hash cost or run the user creation in parallel. Either would change what the test exercises or make the load worse. I ran only
bun test test/parent-link.test.ts: 8 pass, 0 fail. I committed and rangit push, which printed nothing, so I haven't confirmed the push landed.To try it, run
bun test test/parent-link.test.ts. Once the forge's check goes green,shared:01m23vygyffx5hg2f5vm8r74sr:1xc9kwiwzdshould leave the degraded list.Closes #4469