27 lines
1.5 KiB
Markdown
27 lines
1.5 KiB
Markdown
# 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.
|