Correct the factual claim that the cursor advances — it is dead code:
_nextCursor is computed but never persisted by applyBatchFiring/reschedule,
so every tick re-enqueues notifications for every matching exchange in
retention. Clarify that instance-level dedup already works via the unique
index; notification-level dedup is what's broken. Reframe §2 as "make it
atomic before §1 goes live."
Add builder-UX lessons from the njams Server_4 rules editor: clear stale
fields on fireMode toggle (not just hide them); block save on empty
webhooks+targets; wire the already-existing /render-preview endpoint into
the Review step. Add Test 5 (red-first notification-bleed regression) and
Test 6 (form-state clear on mode toggle).
Park two follow-ups explicitly: sealed condition-type hierarchy (backend
lags the UI's condition-forms/* sharding) and a coalesceSeconds primitive
for Inbox-storm taming. Amend cursor-format-churn risk: benign in theory,
but first post-deploy tick against long-standing rules could scan from
rule.createdAt forward — suggests a deployBacklogCap clamp to bound the
one-time backlog flood.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Four focused correctness fixes for the "fire exactly once per FAILED
exchange" use case (alerting layer only; HTTP-level idempotency is a
separate scope):
1. Composite cursor (startTime, executionId) replaces the current
single-timestamp, inclusive cursor — prevents same-millisecond
drops and same-exchange re-selection.
2. First-run cursor initialized to rule createdAt (not null) —
prevents the current unbounded historical-retention scan on first
tick of a new rule.
3. Transactional coupling of instance writes + notification enqueue +
cursor advance — eliminates partial-progress failure modes on crash
or rollback.
4. Config hygiene: reNotifyMinutes forced to 0, forDurationSeconds
rejected, perExchangeLingerSeconds removed entirely (was validated
as required but never read) — the rule shape stops admitting
nonsensical PER_EXCHANGE combinations.
Alert stays FIRING until human ack/resolve (no auto-resolve); webhook
fires exactly once per AlertInstance; Inbox never sees duplicates.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
