Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2eynu2flps is past its budget: trevato/forge: "a token that may only read cannot write through any tool > each admin-scope tool is refused for an rw t… #6323
Check · Review · Land · Live done — Landed and live in production.
This pull raises the time limit on the MCP write-scope tests from 8 s to 60 s. It is a likely fix, not a confirmed one: I could not reproduce the failure, so the cause is unproven.
shipped production is serving it deploy e209d31
This pull raises the time limit on the MCP write-scope tests from 8 s to 60 s. It is a likely fix, not a confirmed one: I could not reproduce the failure, so the cause is unproven.
The test that tripped the sentinel is "each admin-scope tool is refused for an rw token, and nothing changes" in test/mcp-write-scope.test.ts. I ran the file alone and again with six busy-loop processes hogging the CPU. It passed every time, in about 0.85 s. It makes only 8 quick RPC calls, so a hard 8 s limit leaves little reason to fail except a stall on a busy check machine, such as event-loop starvation or GC. I changed that limit and the sibling read-only test's identical 8 s limit. The change touches nothing else in the test or the app code. The assertions are unchanged, so the tests still fail if a gate is removed.
I did not have the check log, so a different cause is possible. If shared:…:2eynu2flps is still in the degraded list after this lands, read the log of the next failure.
The 60 s limit only stops a slow machine failing a test that is otherwise correct. A genuine hang still fails, just later. I ran only this test file, not the whole check. To try it, run bun test test/mcp-write-scope.test.ts.
Two-line change: the 8 s timeout on the two MCP write-scope tests becomes 60 s. The assertions are untouched, so removing a gate still fails them. It serves the CI-lockup/flake direction and adds no feature. There is no UI, so nothing for the preview to show; it is test-only, with no security, terminal or dependency impact.
Two things I would do next:
- Confirm the cause from the next failing check log. Scout could not reproduce the failure, so 60 s may only hide a stall. The first test makes 50+ RPC calls, not 8, so it has the larger budget risk.
- If the stall is real, find it (for example per-call DB setup in rpc or GC) rather than raising limits across the suite.
This pull raises the time limit on the MCP write-scope tests from 8 s to 60 s. It is a likely fix, not a confirmed one: I could not reproduce the failure, so the cause is unproven.
The test that tripped the sentinel is "each admin-scope tool is refused for an rw token, and nothing changes" in
test/mcp-write-scope.test.ts. I ran the file alone and again with six busy-loop processes hogging the CPU. It passed every time, in about 0.85 s. It makes only 8 quick RPC calls, so a hard 8 s limit leaves little reason to fail except a stall on a busy check machine, such as event-loop starvation or GC. I changed that limit and the sibling read-only test's identical 8 s limit. The change touches nothing else in the test or the app code. The assertions are unchanged, so the tests still fail if a gate is removed.I did not have the check log, so a different cause is possible. If
shared:…:2eynu2flpsis still in the degraded list after this lands, read the log of the next failure.The 60 s limit only stops a slow machine failing a test that is otherwise correct. A genuine hang still fails, just later. I ran only this test file, not the whole check. To try it, run
bun test test/mcp-write-scope.test.ts.Closes #6320