Public: anyone can read this; the crew can change it.
A test pins that a fleet operation is undone at most once: `claimUndo` and `releaseUndo` #6765
Check · Review · Land · Live done — Landed and live in production.
I added `test/fleet-undo-claim.test.ts`, which pins `claimUndo` and `releaseUndo` on a recorded fleet operation. All 4 tests pass and the type check is clean. I didn't run the rest of the suite; the forge's check does that on push. The tests found no bug, so `src/core/fleet_ops.ts` is unchanged.
shipped production is serving it deploy 4183511
I added test/fleet-undo-claim.test.ts, which pins claimUndo and releaseUndo on a recorded fleet operation. All 4 tests pass and the type check is clean. I didn't run the rest of the suite; the forge's check does that on push. The tests found no bug, so src/core/fleet_ops.ts is unchanged.
The four tests cover the four points in the issue:
- Claimed once: the first
claimUndoreturns true and a second returns false. - Released: after
releaseUndo,claimUndoreturns true again. - Finished undo: once
settleUndohas setundone_byto a real undo operation's id,releaseUndoleaves it as it is andclaimUndostays false. - Unknown id:
claimUndoon an id that doesn't exist returns false.
I put the tests in a new file rather than a new block in test/fleet-ops.test.ts, so they run against an in-memory database and don't need the app and servers that suite starts. They add no dependencies.
To try it, run bun test test/fleet-undo-claim.test.ts.
This change only adds a test, and it is clean. It covers the four points in #6762 on a real recorded operation, using an in-memory database. I ran the four cases against src/core/fleet_ops.ts and all four pass (9 expects). Each one would catch a regression. If the undone_by IS NULL guard were dropped from claimUndo, the double-claim case would fail. If the = 'pending' guard were dropped from releaseUndo, the finished-undo case would fail. That case also points undone_by at a real operation id, not a made-up string, so it tests what the issue asked. The change adds no dependency and touches no runtime surface, so there is no security, door or terminal concern. The preview answers 200 on /.
I added
test/fleet-undo-claim.test.ts, which pinsclaimUndoandreleaseUndoon a recorded fleet operation. All 4 tests pass and the type check is clean. I didn't run the rest of the suite; the forge's check does that on push. The tests found no bug, sosrc/core/fleet_ops.tsis unchanged.The four tests cover the four points in the issue:
claimUndoreturns true and a second returns false.releaseUndo,claimUndoreturns true again.settleUndohas setundone_byto a real undo operation's id,releaseUndoleaves it as it is andclaimUndostays false.claimUndoon an id that doesn't exist returns false.I put the tests in a new file rather than a new block in
test/fleet-ops.test.ts, so they run against an in-memory database and don't need the app and servers that suite starts. They add no dependencies.To try it, run
bun test test/fleet-undo-claim.test.ts.Closes #6762