1.5 KiB
Campaign Build Recovery
Campaign build is fenced per tenant and Campaign version. Before rendering or writing generated artifacts, Campaign commits a Core recovery operation with the canonical source and validation hashes, the runtime fence, and a reserved opaque object prefix. A repeated idempotency key can replay only a verified successful build; it cannot start a second active build.
Generated EML and bounded print output are written to shared storage and checked for exact size and SHA-256 content. Campaign then commits its jobs and execution snapshot, compares the stored object and database manifests, and records verified success. A managed Files output makes the operation forward-recoverable because Campaign cannot undo a Files-owned artifact; object-only builds use explicit compensation.
If the Campaign database transaction fails, Campaign deletes every object it recorded and verifies absence before recording recovered state. Failed deletion, an unavailable storage check, process loss, or superseded-object cleanup failure leaves a recovery-required operation visible in Ops. Do not retry such an operation as a normal build. Verify its checkpoint chain and reserved prefix, then reconcile it through the owning-module procedure. The orphan inventory reconciler tracked in Campaign issue 91 will automate that bounded inspection.
No recovery checkpoint contains message bodies, recipients, credentials, or resolved provider secrets. Object keys remain restricted diagnostics rather than Campaign business data.