Compute
Retry delivery without rerunning the job
Reauthorize the destination and resume the accepted bundle you already have. A delivery failure never justifies resubmitting a job that already succeeded and was already charged.
Confirm the job actually succeeded
Before you touch delivery, check the job. If it reached SUCCEEDED and result-manifest.json is present, the work is finished and the bundle is yours.
That bundle does not need making again. It was produced under your approved quote, it was charged, and its receipt already proves both.
A delivery failure is a transport problem in front of a finished result. Resubmitting the job at this point buys a second copy and a second charge.
Find out what actually failed
Read the delivery state and its next action. The common causes separate cleanly.
AUTHORITY_EXPIRED— the destination authority lapsed. Nothing is wrong with your store.WRITE_FAILED— the destination was unreachable or refused the write.VERIFY_FAILED— bytes landed but did not match the manifest.CUSTOMER_REGISTRATION_FAILED— the write reached your store and your own registration step failed.
Each carries a safe reason and a concrete next action. Fix that cause before you retry, or the retry reproduces it.
Reauthorize and resume
- Test the destination and read the result back, so you know it is healthy now.
- Obtain a fresh destination authority for the same accepted bundle.
- Resume the delivery against that bundle, not against a new job.
- Let it run to
VERIFIED, then toCOMMITTED. - Acknowledge the delivery once your own registration succeeds.
Step two is where an expired authority is repaired. Renewing an authority never reruns Compute — it renews permission to move bytes that already exist.
Preserve the original evidence
Keep the original job reference, its receipt and its manifest through every retry. They stay the evidence for the work, whatever delivery does afterwards.
Delivery attempts are recorded independently. Several attempts against one accepted bundle is normal, and each keeps its own state, timestamps and outcome.
Never reconcile a retry by editing the original record. The clean picture is one job, one receipt, and a list of delivery attempts beneath it.
What success looks like
The delivery record reaches COMMITTED, then CUSTOMER_ACKNOWLEDGED. The object in your store matches the manifest's file list, byte counts and declared digests.
The job reference and receipt are unchanged, and you were charged once. Your attempt history explains what happened without needing a note beside it.
When a rerun is genuinely the answer
Rerun only when the compute result itself is wrong or incomplete — a PARTIAL job, or items in failures/ you have since fixed the input for.
Even then, rerun the affected items rather than the whole job. Read failures, abstentions and disagreements first to work out which ones those are.
If a delivery cannot be made to work after the cause is fixed, raise it with support using the job reference and the delivery reference. Support never needs a payload dump, a key, a signed link or bank details. Every state and its next action is listed in delivery states and acknowledgements.