The Rust commerce HTTP layer stores retry receipts in the selected commerce database.
These are distinct from native governed command receipts and provider idempotency keys.
Back up the tenant database to preserve its business state and completed responses together.
Keep the original request
Retain Idempotency-Key, route, exact request content, tenant/store and authentication context
before dispatch. Required-key routes return 428 when the key is missing; a reused key with a
changed fingerprint returns 422. Authentication and authorization precede replay.
Do not change keys after a lost response to make a request run again.
A pending receipt has response_status = 0 and never automatically expires. The mutation
may already have committed even if the response could not be stored. Age, process restart,
or a later rejection does not prove rollback. Inspect the business/provider record first.
Inspect pending work without changing it
From the source checkout, the native operator example opens an existing store read-only,
without creating it or running migrations:
Inspection is tenant-scoped and bounded to the oldest 1,000 pending summaries, including exact
reservation times. For a single-tenant store the empty tenant is explicit. Library pending
inspection exists on SQLite and PostgreSQL; do not use direct SQL deletion as a retry strategy.
Reconcile a verified SQLite outcome
Stop the original worker and verify the business/provider result. Prepare operator-owned
HttpReceiptResolution JSON with original tenant, key, fingerprint, reservation time, verified
response and incident/evidence attribution. Preview first:
Completion compares the exact pending identity and writes the verified response with a
required audit entry atomically. Stale or repeated resolution conflicts. Audit failure leaves
it pending. The helper does not rerun the mutation, delete the receipt, prove worker termination,
or verify external settlement. It is operator-only and outside the MCP catalog.
The audited helper is SQLite-specific; PostgreSQL has pending inspection and its existing
fingerprint-checked completion API. Scope, API and evidence must match the backend. Resume
clients only after reconciling the original outcome and confirming same-key behavior.
For HTTP authentication and tenant setup see API hardening.
For storage failure and restore see backup/recovery. Last modified on October 20, 2026
