mix aurora_meter.events.backfill (Aurora Meter v1.0.0)

View Source

Fills event_id, payload_hash, occurred_at, period_start and attribution on every aurora_meter_events row written before core schema version 7.

mix aurora_meter.events.backfill -r MyApp.Repo

Run it between core schema version 7 and version 8. Version 8 makes event_id NOT NULL behind a unique index and refuses to run while any row still has a null one.

It is bounded, checkpointed and safe to re-run: the cursor lives in aurora_meter_checkpoints under "events_backfill", every update carries WHERE event_id IS NULL, and the identity of a legacy row is derived from its own primary key, so two runs produce the same bytes. Killing it loses at most the batch in flight.

Options

  • -r, --repo: the repo to work through. Defaults to the configured one.
  • --batch-size N: rows per transaction. Default 5000.
  • --max-batches N: stop cleanly after N committed batches, for a bounded maintenance window. Re-run to continue.
  • --dry-run: scan and compute, change nothing, print the counts. Use it to see nonpositive_quantity and oversized_metadata before deciding whether version 8 can validate the check constraints.
  • --force-resume: proceed although the checkpoint says "running", which is what a previous run killed mid-batch leaves behind.
  • --stale-after N: seconds after which such a checkpoint is described as stale in the refusal message. Default 900. It changes no behaviour: the refusal itself is decided by a Postgres advisory lock, never by a clock.
  • --timeout N: milliseconds allowed for one statement and one batch transaction. Default 60000. Raise it alongside --batch-size: the database driver would otherwise apply its own 15 second default, which is a sensible bound for a request and the wrong one for bulk work.

What it approximates

occurred_at is set to inserted_at, because AuroraMeter.track/4 never recorded when the usage happened. Those rows are exactly the ones whose event_id begins legacy:. Where the period source cannot place the instant, period_start is the calendar month containing it and attribution is "unresolved"; every other backfilled row is "resolved". Nothing else is guessed, and no row is projected into aurora_meter_event_totals: a legacy event was never billed and must not become billable by being upgraded.