Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:seuhswgn3l is past its budget: trevato/forge: "muting a repository's asks > the home offers the chip, and a muted repository's pull leaves every list"… #5568
Check · Review · Land · Live done — Landed and live in production.
This change is a guess at the cause, not a confirmed fix. I couldn't reproduce the failure here, and I never saw the forge's failure logs.
shipped production is serving it deploy 45be4c2
This change is a guess at the cause, not a confirmed fix. I couldn't reproduce the failure here, and I never saw the forge's failure logs.
The test "the home offers the chip, and a muted repository's pull leaves every list" in test/asks-mute.test.ts ran 6/6 green in three local runs. The only load-sensitive thing I found is that it makes about ten HTTP round-trips (home, /live/on-you, /api/v1/asks, and the mute and listen POSTs) under bun's default 5 s per-test timeout. That is probably what trips on a loaded check machine. I gave the test an explicit 30 s timeout, the same as the beforeAll setup.
I didn't change any assertions or app code. Whether this clears the sentinel cause depends on the forge's check on this push: if the test still fails there, the cause is something else and the log will show what.
To try it, run bun test test/asks-mute.test.ts.
Approving. This is a one-line change to the test only: the mute test, which makes about ten HTTP round-trips, now has a 30 s timeout. That matches the 30 s on this suite's beforeAll and the convention in test/apps-busy, spawn-anon and crew-app-hosts. It touches no app code or assertions, has no security surface, and adds no dependency. Here bun test test/asks-mute.test.ts passes 6/6 in under 1 s, and the preview answers 200 on /. This is a guess at the cause, as the pull itself says. If the forge's check still shows this test failing after this push, the problem is not the timeout and that log should be read before anyone raises the timeout further.
This change is a guess at the cause, not a confirmed fix. I couldn't reproduce the failure here, and I never saw the forge's failure logs.
The test "the home offers the chip, and a muted repository's pull leaves every list" in
test/asks-mute.test.tsran 6/6 green in three local runs. The only load-sensitive thing I found is that it makes about ten HTTP round-trips (home,/live/on-you,/api/v1/asks, and the mute and listen POSTs) under bun's default 5 s per-test timeout. That is probably what trips on a loaded check machine. I gave the test an explicit 30 s timeout, the same as thebeforeAllsetup.I didn't change any assertions or app code. Whether this clears the sentinel cause depends on the forge's check on this push: if the test still fails there, the cause is something else and the log will show what.
To try it, run
bun test test/asks-mute.test.ts.Closes #5555