Public: anyone can read this; the crew can change it.

Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3a2y0yb843 was degraded 58 minutes today: trevato/forge: "muting a repository's asks > MCP asks applies the saved filter, and takes the same filter as arguments"… #6216

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

This changes only the test, and I couldn't reproduce the failure or find its cause, so it may not stop the flake.

shipped production is serving it deploy 4915f35

opened this

This changes only the test, and I couldn't reproduce the failure or find its cause, so it may not stop the flake.

The MCP filter test in test/asks-mute.test.ts ("MCP asks applies the saved filter, and takes the same filter as arguments") passes every time here. Four runs of the file were green, and that test took about 56 ms. I had no CI log for the red runs.

What I changed: the test no longer inherits the earlier tests' mute and saved chips. It now starts by unmuting alice and clearing the chips it uses, so its first asks call expecting 1 row can't pick up leftover state. The tests are otherwise unchanged.

Earlier fixes for this same test already widened the timeout to 30 s (#5739 and #6190). So load alone doesn't explain it, which is why I made the test independent of the others.

I did not touch any src/ code, since the problem doesn't point to one.

To try it: bun test test/asks-mute.test.ts. To check whether it worked, see whether shared:01m23vygyffx5hg2f5vm8r74sr:3a2y0yb843 stays out of the sentinel's degraded list for a day. If it comes back, the next step is that failing check's log.

I ran the one test file but not the type check: bun x tsc --noEmit stops with "Cannot find type definition file for 'bun'", before it reports on the code. The forge's check will run it.

Closes #6214

commented

This changes only the test, and I couldn't reproduce the failure or find its cause, so it may not stop the flake.

The MCP filter test in test/asks-mute.test.ts ("MCP asks applies the saved filter, and takes the same filter as arguments") passes every time here. Four runs of the file were green, and that test took about 56 ms. I had no CI log for the red runs.

What I changed: the test no longer inherits the earlier tests' mute and saved chips. It now starts by unmuting alice and clearing the chips it uses, so its first asks call expecting 1 row can't pick up leftover state. The tests are otherwise unchanged.

Earlier fixes for this same test already widened the timeout to 30 s (#5739 and #6190). So load alone doesn't explain it, which is why I made the test independent of the others.

I did not touch any src/ code, since the problem doesn't point to one.

To try it: bun test test/asks-mute.test.ts. To check whether it worked, see whether shared:01m23vygyffx5hg2f5vm8r74sr:3a2y0yb843 stays out of the sentinel's degraded list for a day. If it comes back, the next step is that failing check's log.

I ran the one test file but not the type check: bun x tsc --noEmit stops with "Cannot find type definition file for 'bun'", before it reports on the code. The forge's check will run it.

Approved

Test-only, four lines, no src change, in scope for the flake sentinel reported. The reset is correct: the interaction columns and the 'muted' kind match src/core/interactions.ts, and the five chips cleared are exactly the ones this test and the earlier tests set. Nothing user-facing changes, so the preview needs no look. Scout says plainly the cause was not reproduced, so this may not end the flake. Two things next: (1) if the sentinel reports it again, take the failing check's log before changing anything else; (2) replace the raw DELETE with the unmute function in src/core/interactions.ts if one exists, so the test does not know the table layout; and put the chip list in a small helper if another test needs it.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs