test(backfill): the two cutoff guards pin reachability, not text order (#1149)

[lilyshen0722]

Closes #1149.

Both tests in backend/__tests__/unit/models/threadingCutoffRecord.test.js are described as pinning control-flow properties of backend/scripts/backfill-thread-root-id.ts, and both assert them with SCRIPT.indexOf position comparisons. @sprint-review mutated each at c0da084f and both stayed green on a script carrying the regression the test's own comment names — a text-position comparison cannot see a return.

the UPDATE and the ledger INSERT are one transaction — a bare return between the UPDATE and the INSERT leaves begin < update < insert < commit intact and makes the ledger write unreachable. Now also asserts SCRIPT.slice(update, insert) contains no return/throw/process.exit.

a run that finds the ledger row reports it and never re-measures — the property is that it stops, which rests entirely on the return at :209. Deleting that one line leaves both indices unchanged and the script re-measures anyway, printing the oldest reply ever written as a "would record" value: the exact failure #1148 was written to remove. Now also asserts the reported-and-stopped block contains a return.

Verification

34/34 green unmutated (Node 22 — Node 26 kills any suite importing buffer-equal-constant-time; this suite doesn't, but the pin is why the local run is on 22).

Negative control, each of #1149's two mutants applied in isolation and reverted:

mutant	reddens
if (process.env.SKIP_LEDGER) return; between UPDATE and INSERT	exactly the UPDATE and the ledger INSERT are one transaction (1 failed / 33 passed)
delete return; at :209	exactly a run that finds the ledger row reports it and never re-measures (1 failed / 33 passed)

A first pass ran mutant B on top of an un-reverted mutant A and reported two failures; re-run in isolation, each mutant reddens exactly the one test whose comment describes it. The script is restored clean — no production change in this PR.

Scope note

#1170 did not retire these. It was additive (+111 −0) and its 11 executing cases cover CUTOFF_SQL's semantics; the 5 remaining toBeLessThan assertions are statement-ordering claims over the script source, which is orthogonal. Three of the five (the transaction chain) are kept and now backed by a reachability assertion; the other two are the ledger-read ordering, likewise kept and backed.

Candidate review-checklist rule, from #1149: a test that compares source positions pins text order, never control flow — if the property is "it stops", the guard must look for the thing that stops it. Not added here; that's a separate doc change.

🤖 Generated with Claude Code

[lilyshen0722]

Reproduced the whole demonstration at 4a9c1f16. Baseline 38/38 across both suites. Both mutants restored independently, each harness run separately:

delete the early return (:221)            executing  2 failed / 2 passed    text guard  1 failed / 33 passed
if (ledger && <never true>)               executing  3 failed / 1 passed    text guard  34 passed  (ALL GREEN)

The second row is the argument and it holds exactly as stated — no string moves, so no scan over the source can see it. The export is clean: require.main === module is untouched, and the suite importing main without exiting the worker is itself the evidence that importing runs nothing. (Minor: the early return is :221 at this head, not :209.)

The residue is measured, not just predicted — and it is inside the harm this guard was written for. The transaction test's own comment says "losing the INSERT after the UPDATE leaves every chain rooted and no cutoff recorded." I gated that INSERT on a never-true condition, moving no anchor (BEGIN :352, COMMIT :393, ROLLBACK :395 all still singular and in order):

text guard (threadingCutoffRecord)        34 passed
executing (threadingCutoffLedgerFirst)     4 passed
                                          38/38 green

So the specific defect the guard names in its rationale is one of the mutants it cannot detect, and nothing else in the tree catches it either. That is a stronger statement than "blind to a class of mutants", and it is the one the next reader needs.

Not asking you to close it here. The scoping call is right — reaching the APPLY path needs argv flags and a seeded population, which is more than this PR should carry. And the guard is as good as its instrument allows: I counted the anchors and they are all unique (UPDATE messages m 1 hit; INSERT INTO migration_records (name, details) has a twin at :267, and lastIndexOf is the correct pick). Worth landing as-is.

The one change I would make is to the residue comment: state the measurement rather than the category. "Blind to every mutant that removes reachability without a keyword" reads as a theoretical caveat; "the ledger INSERT can be made unreachable with all four anchors intact and both suites green" reads as what it is.

[lilyshen0722]

Verified b7777a68 / ac5a7f9d — the Tier 1 move closes the residue, and I ran the mutant that made it a residue rather than a class.

Against a real postgres 16 with config/schema.sql loaded (INTEGRATION_TEST=true, --runInBand), baseline is green: 3/3 forward + backward + idempotent-second-run.

Then the exact mutant: if (false as boolean) in front of the ledger INSERT at :379.

Tier 0  threadingCutoffRecord.test.js                34 passed, 34 total   (blind)
Tier 1  service/threading.backfillTransaction.test.js  3 failed,  3 total   (catches)

All three fail, not just FORWARD — so the BACKWARD arm isn't decorative either. That's the discrimination the comment claims, measured rather than argued.

Two smaller confirmations:

• e1872c2f: all three citations now anchor on a symbol or a quoted string. nativeRuntimeService.ts:512 cites Raw-type gate mirrors the wrapper's claimable set and records its own 43-line drift; the lifecycle test cites requeueResult = await AgentEvent.updateMany and deleteMany({ status: 'pending' ... }). The :209→:221 figure in the test comment is exact — I measured the return at 209 on origin/main and 221 at the head, and the export hunk is @@ -161,15 +161,27 @@, +12.
• 56 green reproduced at e1872c2f, as 34 + 18 + 4 — the two suites the commit edits, plus nativeRuntimeService.claims.test.js as the guard for the source file it edits. And 38 for the two unit suites together, matching the new comment.

One thing worth knowing rather than changing: this is now the only executing check for atomicity, and it lives behind needs: test in the Tier 1 job. The concurrency comment at the top of tests.yml measured that job surviving 0 of 14 cancelled runs before the per-SHA grouping fix. The fix is in, so this is fine today — but the property's whole cost of being real is that it rides the deepest job in the graph.