Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3a2y0yb843 is past its budget: trevato/forge: "muting a repository's asks > MCP asks applies the saved filter, and takes the same filter as arguments"… #5477
Check · Review · Land · Live done — Landed and live in production.
This pull gives the flaky MCP asks test a 30-second timeout so it stops failing when the check machine is under load. I'm fairly confident that's the cause, but I couldn't reproduce the failure here. I never saw a log of the failing run.
shipped production is serving it deploy 7cfd21c
This pull gives the flaky MCP asks test a 30-second timeout so it stops failing when the check machine is under load. I'm fairly confident that's the cause, but I couldn't reproduce the failure here. I never saw a log of the failing run.
The test "MCP asks applies the saved filter, and takes the same filter as arguments" in test/asks-mute.test.ts makes about a dozen sequential HTTP round trips to the MCP endpoint. It was running under bun's default 5-second limit, which a loaded machine can exceed. In the sandbox the file passes in about 1.3–2s.
The test's assertions are unchanged.
I only re-ran test/asks-mute.test.ts (6 pass). I didn't run the type check or the whole suite.
I did not cut the number of round trips or restructure the test; if the sentinel stays red after this, the cause is something other than the timeout and needs the failing log.
A one-line, test-only change: the MCP asks test now has a 30s timeout instead of bun's 5s default. Assertions are untouched and the timeout argument is valid bun:test syntax. The preview answers / with 200. No product code, security surface or dependency changes. The cause is not proven, since scout never saw the failing log. Two things I would do next: (1) if the sentinel stays red, get the failing log, because a dozen local round trips should take ~1-2s and a 5s overrun may be a real slow path; (2) split the test into the saved-filter, bad-filter and manifest checks so each runs well under the limit.
This pull stops "MCP asks applies the saved filter, and takes the same filter as arguments" in test/asks-mute.test.ts from failing when the check machine is under load. It does that by giving the test a 30-second timeout instead of bun's default 5 seconds.
I'm fairly confident the 5-second limit is the cause, but I couldn't reproduce the failure and never saw a log of a failing run. The test makes about a dozen sequential HTTP round trips to the MCP endpoint, which passes in about 1.3–2s in the sandbox. A loaded machine could plausibly push it past 5 seconds.
The test's assertions are unchanged. I re-ran test/asks-mute.test.ts (6 pass), but not the type check or the whole suite.
I did not cut the number of round trips or restructure the test. If the sentinel stays red after this lands, the cause is something other than the timeout, and the failing check's log is what's needed to find it.
The newest message on the issue is an automatic triage note filing it under P0 Trust, so it changed nothing in the fix.
This pull gives the flaky MCP asks test a 30-second timeout so it stops failing when the check machine is under load. I'm fairly confident that's the cause, but I couldn't reproduce the failure here. I never saw a log of the failing run.
The test "MCP asks applies the saved filter, and takes the same filter as arguments" in
test/asks-mute.test.tsmakes about a dozen sequential HTTP round trips to the MCP endpoint. It was running under bun's default 5-second limit, which a loaded machine can exceed. In the sandbox the file passes in about 1.3–2s.The test's assertions are unchanged.
I only re-ran
test/asks-mute.test.ts(6 pass). I didn't run the type check or the whole suite.I did not cut the number of round trips or restructure the test; if the sentinel stays red after this, the cause is something other than the timeout and needs the failing log.
Closes #5443