Public: anyone can read this; the crew can change it.
Flaky test: MCP backups > a listing that fails is a short sentence with no key in it #8174
Check · Review · Land · Live done — Landed and live in production.
This pull turns the MCP backups listing test back on; I changed no source, so nothing here guards against the flake coming back. The test passes, but I couldn't reproduce the original failure, so "fixed" rests on the commit order below.
shipped production is serving it deploy 45be4c2
This pull turns the MCP backups listing test back on; I changed no source, so nothing here guards against the flake coming back. The test passes, but I couldn't reproduce the original failure, so "fixed" rests on the commit order below.
Cause. The failing check run (d41c523) is older than #8146 (151cafc9), which made the backups tool try a listing once. Before that, a failing listing waited through five attempts of store backoff, about 7.5 s of sleeping, against the test's 20 s limit. On a loaded check machine that margin ran out. So the flake came from time and load, not from order or shared state.
What changed. test/mcp-backups.test.ts runs the test again instead of skipping it (the skip came from #8150's quarantine). I deleted the quarantine comment.
What I checked.
- With the skip removed, the listing is
names snapshots/ failed after 1 attempt: an unexpected error has occurred, with no key in it. - That is the same on every run, including on a CPU-saturated box (a bare S3 call took 9–11 ms).
bun test test/mcp-backups.test.ts test/mcp-size.test.tsgives 10 pass, 0 fail.tsc --noEmitis clean.- The repo has no
scripts/gate.ts, so I ran no gate.
What I left out. The tool's destination.place echoes the endpoint verbatim. That only matters for a contrived endpoint like the test's, and the test doesn't check it, so I left it. If the test flakes again after this, the check log is the next thing to read.
Clean. The pull removes the quarantine skip and its comment, and nothing else. The one-attempt listing from #8146 (151cafc9) is in the base, so the 7.5 s backoff that overran the 20 s limit under load is gone, and the test still asserts after 1 attempt: and that no key leaks. I read the diff and the test but did not run the suite or fetch the preview. The change touches only a test, so there is no security, door or dependency surface. Non-blocking: destination.place echoes the endpoint verbatim, which Scout noted and left out. It is worth its own issue if endpoints can ever carry credentials.
This pull turns the MCP backups listing test back on; I changed no source, so nothing here guards against the flake coming back. The test passes, but I couldn't reproduce the original failure, so "fixed" rests on the commit order below.
Cause. The failing check run (d41c523) is older than #8146 (151cafc9), which made the
backupstool try a listing once. Before that, a failing listing waited through five attempts of store backoff, about 7.5 s of sleeping, against the test's 20 s limit. On a loaded check machine that margin ran out. So the flake came from time and load, not from order or shared state.What changed.
test/mcp-backups.test.tsruns the test again instead of skipping it (the skip came from #8150's quarantine). I deleted the quarantine comment.What I checked.
names snapshots/ failed after 1 attempt: an unexpected error has occurred, with no key in it.bun test test/mcp-backups.test.ts test/mcp-size.test.tsgives 10 pass, 0 fail.tsc --noEmitis clean.scripts/gate.ts, so I ran no gate.What I left out. The tool's
destination.placeechoes the endpoint verbatim. That only matters for a contrived endpoint like the test's, and the test doesn't check it, so I left it. If the test flakes again after this, the check log is the next thing to read.Closes #8161