wake/reconcile (pilot #7, alarm-hygiene): re-enumerates CONSUMED detector states → dup wake + spurious rc=1 CRITICAL → store records last-consumed observed_hash as 3rd accounted check #932

Closed
opened 2026-07-26 13:20:16 +00:00 by jason.woltje · 0 comments
Owner

Pilot finding #7 (dragon-lin), A-lane, NORMAL cadence — joins the residual queue AFTER #917/#925. Safe-but-noisy alarm-hygiene defect.

Defect. The reconciler RE-ENUMERATES already-CONSUMED detector-observed states. After consume-truncation, a consumed state matches NO accounting record — the inbox is truncated, the seen-ledger only covers the reconciler's OWN enumerations, and the detector hash-file is (correctly) distrusted — so the reconciler treats it as unaccounted and re-enumerates it. Result: one DUPLICATE orientation wake + one SPURIOUS rc=1 CRITICAL alarm per detector-active window per cycle. Functionally safe (no lost obligation), but NOISY — the real cost is G2a ALARM HYGIENE at fleet scale: cry-wolf erosion kills real alarms.

RULED SCALPEL (Mos). At consume-truncation, the STORE records the last-consumed observed_hash per (kind,id); the reconciler adds it as its THIRD accounted check (alongside the inbox/observed_seq and its own seen-ledger).

Trust argument (load-bearing — verbatim). A store-side record is trustworthy for the reconciler BY CONSTRUCTION — its existence implies the state WAS durably enqueued; the §5 swallow hole's signature is hash-advance-WITHOUT-enqueue, which this record structurally cannot exhibit. The rejected alternative (reconcile trusting detector hash-files) STAYS REJECTED — it would reopen §5.

Red-first: a CONSUMED state does NOT re-enumerate (no dup wake, no spurious CRITICAL); AND a genuinely-unaccounted state STILL re-enumerates (the anti-swallow catch keeps its teeth — do NOT weaken G3).

Pilot evidence: seqs 20/21 byte-matched to consumed 18/19 (re-enumerated the just-consumed states); the follow-up cycle was clean.

Refs: #892, #908 (store allocator / seen-ledger), §5 swallow hole (why detector-hash-files stay distrusted), #920/#924 (co-feed + alarm hygiene). Priority: normal cadence, after #917.

Pilot finding #7 (dragon-lin), A-lane, NORMAL cadence — joins the residual queue AFTER #917/#925. Safe-but-noisy alarm-hygiene defect. **Defect.** The reconciler RE-ENUMERATES already-CONSUMED detector-observed states. After consume-truncation, a consumed state matches NO accounting record — the inbox is truncated, the seen-ledger only covers the reconciler's OWN enumerations, and the detector hash-file is (correctly) distrusted — so the reconciler treats it as unaccounted and re-enumerates it. Result: one DUPLICATE orientation wake + one SPURIOUS `rc=1` CRITICAL alarm per detector-active window per cycle. Functionally safe (no lost obligation), but NOISY — the real cost is **G2a ALARM HYGIENE at fleet scale: cry-wolf erosion kills real alarms.** **RULED SCALPEL (Mos).** At consume-truncation, the STORE records the last-consumed `observed_hash` per `(kind,id)`; the reconciler adds it as its THIRD accounted check (alongside the inbox/observed_seq and its own seen-ledger). **Trust argument (load-bearing — verbatim).** A store-side record is trustworthy for the reconciler BY CONSTRUCTION — its existence implies the state WAS durably enqueued; the §5 swallow hole's signature is hash-advance-WITHOUT-enqueue, which this record structurally cannot exhibit. The rejected alternative (reconcile trusting detector hash-files) STAYS REJECTED — it would reopen §5. **Red-first:** a CONSUMED state does NOT re-enumerate (no dup wake, no spurious CRITICAL); AND a genuinely-unaccounted state STILL re-enumerates (the anti-swallow catch keeps its teeth — do NOT weaken G3). **Pilot evidence:** seqs 20/21 byte-matched to consumed 18/19 (re-enumerated the just-consumed states); the follow-up cycle was clean. Refs: #892, #908 (store allocator / seen-ledger), §5 swallow hole (why detector-hash-files stay distrusted), #920/#924 (co-feed + alarm hygiene). Priority: normal cadence, after #917.
Mos closed this issue 2026-07-26 15:48:42 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#932