Rebuilds aurora_meter_event_totals from the events that produced it, into an isolated generation, while the system keeps recording.

{:ok, report} = AuroraMeter.Events.Replay.run()
AuroraMeter.Events.Replay.status()
AuroraMeter.Events.Replay.prune(1)

A replay is an operator action, not a scheduled job. Nothing runs one by itself: AuroraMeter.Oban schedules no replay, and the runbook (replay) says when to run one and what it costs.

What makes a forward scan sound here

The events table is being written while the scan reads it, and two obvious keyset orders are unsound: id is a random version 4 UUID, so a transaction that started earlier can commit a row below a cursor the scan has passed, and inserted_at is an application clock value rather than a commit order. The scan orders by seq, the database-assigned identity column, and is bounded by a watermark:

• AuroraMeter.Storage.begin_projection_generation/0 takes FOR UPDATE on the events_projection checkpoint row. Every record and correction transaction takes FOR SHARE on that same row before inserting anything, so the exclusive lock is granted only once every in-flight one has finished. max(seq) read in that transaction is therefore a line every committed event is below.
• Every record that starts afterwards reads the building generation in its own first step and writes its delta to both generations. Those events are above the watermark and the scan never sees them.

There is no third case, which is what makes "no event is missing and none is counted twice" provable rather than likely.

What a replay never does

It reads aurora_meter_events and writes aurora_meter_event_totals and its own checkpoint rows. It never calls AuroraMeter.record/4, so it stages no export intent and inserts no event. It never grants a credit, never marks a counter key dirty, never writes pending_flush, never publishes a PubSub message and never calls a host handler. A rebuilt projection therefore cannot cause a resend, a second invoice line or a duplicate notification (I08).

Exclusion, and why there is no lease

Two runners are kept apart by AuroraMeter.Checkpoints.claim/3, a Postgres session advisory lock on a pinned connection. It dies with the connection, so a runner killed with kill -9 leaves nothing to expire. The heartbeat in the checkpoint cursor is a report for a human and nothing subtracts it from anything: open-findings.md X100 measured the one clock every node shares stepping backwards 439 ms on a 32.5 second cadence, and a lease compared against it can invert.

Repo-bound, like the backfill

Each batch commits its totals and its checkpoint in one transaction, which is the whole of the resumability guarantee, so this module opens that transaction on AuroraMeter.Config.repo/0 directly, exactly as AuroraMeter.Checkpoints and AuroraMeter.Events.Backfill do. An adapter that does not declare :projection_generations is refused up front with {:error, {:unsupported, :projection_generations}} rather than half served.