Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:13750cmn0i is past its budget: trevato/forge: "MCP backups > a listing that fails is a short sentence with no key in it" failed on 12 pulls in the las… #8175
Check · Review · Land · Live done — Landed and live in production.
I un-skipped "MCP backups > a listing that fails is a short sentence with no key in it" and changed it to fail against a local server. I never saw the original flake fail. It passed in my runs, so the cause is a guess. The un-skipped test passed three runs in a row here, and `tsc --noEmit` is clean. I did not run `scripts/gate.ts` or `test/mcp-size.test.ts`: the change is test-only, so neither is…
shipped production is serving it deploy bbd5a0b
I un-skipped "MCP backups > a listing that fails is a short sentence with no key in it" and changed it to fail against a local server. I never saw the original flake fail. It passed in my runs, so the cause is a guess. The un-skipped test passed three runs in a row here, and tsc --noEmit is clean. I did not run scripts/gate.ts or test/mcp-size.test.ts: the change is test-only, so neither is touched.
- What changed: the test was quarantined with
test.skipin #8150. It used to make the listing fail by pointingS3_ENDPOINTat a malformed URL, so its verdict depended on how Bun's S3 client handles garbage. It now points at aBun.serveloopback server on a random port that answers 500 and echoes the secret and access key in its body. The assertions are unchanged: one attempt, at most 200 characters, and neither key in the text. No product code changed. - What I couldn't prove: my sandbox refused the loopback connections, so the S3 client got an error without reaching the server. The assertions held either way, but I did not see the 500 path itself exercised. The forge's check will run it unsandboxed.
- What I left out:
scrubReasonstill has its own unit test for the key-stripping and length cap. I did not touch the retry logic insrc/snapshot/store.ts. - To try it: run
bun test test/mcp-backups.test.ts. The sentinel cause should clear once main goes green.
Test-only, no product code touched, no secrets (the fake keys are fixtures). The loopback Bun.serve on port 0 is stopped in finally, the env is restored, and the assertions are unchanged: one attempt, at most 200 characters, and neither key in the text. The listing path in src/http/mcp/tools/backups.ts goes through s3Store with one attempt and scrubReason, so a 500 that echoes the keys exercises the code the test names. Caveats: the flake cause is a guess and the 500 path was not seen running in the builder sandbox. If it flakes again, quarantine it again and open an issue rather than loosen the assertions.
I un-skipped "MCP backups > a listing that fails is a short sentence with no key in it" and changed it to fail against a local server. I never saw the original flake fail. It passed in my runs, so the cause is a guess. The un-skipped test passed three runs in a row here, and
tsc --noEmitis clean. I did not runscripts/gate.tsortest/mcp-size.test.ts: the change is test-only, so neither is touched.test.skipin #8150. It used to make the listing fail by pointingS3_ENDPOINTat a malformed URL, so its verdict depended on how Bun's S3 client handles garbage. It now points at aBun.serveloopback server on a random port that answers 500 and echoes the secret and access key in its body. The assertions are unchanged: one attempt, at most 200 characters, and neither key in the text. No product code changed.scrubReasonstill has its own unit test for the key-stripping and length cap. I did not touch the retry logic insrc/snapshot/store.ts.bun test test/mcp-backups.test.ts. The sentinel cause should clear once main goes green.Closes #8163