ADR-001: Two-phase manifest publish¶
Status: Accepted (2026-03-14)
Source: historical-notes/2026-03-14-manifest-history-and-rollback.md
Context¶
Writers produce per-shard databases plus a manifest enumerating them. Readers need:
- Atomic visibility: a snapshot is either fully visible or not at all.
- Rollback: revert
_CURRENTto a previous manifest without re-uploading data. - History: keep prior manifests addressable for audit.
A naive single-write publish (overwrite a manifest key) loses history and races readers.
Decision¶
Publish in two phases:
- Phase 1 — Write manifest at
manifests/<timestamp>_run_id=<run_id>/manifest. Path is content-addressable by run; prior manifests remain. - Phase 2 — Swap
_CURRENTto point at the new manifest ref._CURRENTis the only mutable pointer.
_CURRENT carries its own format_version: int = 1 (separate from manifest format version).
Consequences¶
- Atomic visibility flips on the
_CURRENTswap. - Rollback =
set_current(<old ref>). No data movement. - History = list of
manifests/*keys, ordered by timestamp (%Y-%m-%dT%H:%M:%S.%fZ). - Old manifest data accumulates in S3 until
cleanupreaps unreferenced shards.
Related¶
architecture/manifest-and-current.md- ADR-003 (run registry — required for safe cleanup).