Compute Help
Delivery to your destination failed
Your Compute job succeeded but the result never reached your destination? Renew the destination authority, check for a conflict or a committed write, and retry delivery without rerunning the job.
The job succeeded, but the write to your destination did not.
The work finished but the write did not
Your job reached SUCCEEDED and the result bundle exists. What failed is the separate step that writes it to your destination.
The Compute result is already accepted and already paid for. Nothing about a failed write changes that, and nothing about it needs the work repeated.
Read the delivery state
Delivery has its own state machine, kept apart from the job for exactly this reason. Read it before you touch anything.
The normal path runs PLANNED, AUTHORITY_READY, WRITING, WRITTEN_UNVERIFIED, VERIFIED, COMMITTED, then CUSTOMER_ACKNOWLEDGED.
The failure states name the cause: AUTHORITY_EXPIRED, WRITE_FAILED, VERIFY_FAILED, COMMIT_CONFLICT, CUSTOMER_REGISTRATION_FAILED, QUARANTINED and CANCELLED.
Then do this
- AUTHORITY_EXPIRED. The credential for your destination lapsed. Re-register or test the destination, then retry delivery. Only the authority is renewed; the result stays exactly as it is.
- WRITE_FAILED or VERIFY_FAILED. The destination refused the write, or the written bytes did not verify. Fix the destination, then retry.
- COMMIT_CONFLICT. Something else wrote to the same target. Read the target and find out whether the write already committed before you write again.
- CUSTOMER_REGISTRATION_FAILED. The bytes landed but your own registration step did not complete. Finish that step rather than rewriting.
- QUARANTINED. Delivery is held pending review. Read the next action on the response and follow it.
Retry delivery from the result you already hold. The bundle is immutable, so a retry writes identical bytes.
What not to repeat
Never rerun the job to fix a delivery problem. You would pay for the same work twice and receive the same bytes.
Never write again into a COMMIT_CONFLICT without checking the committed state first. That is how a destination ends up holding the same result twice.
Get help safely
Send the job reference, the delivery state you observed, and the request ID. Add the operation name, your client version, the contract release, and the time with its time zone.
Name the destination by its registered name only. Never send its credential, a signed URL, a payload, or banking information.
Read more about retrying delivery without rerunning work and registering a destination.
Still blocked?
Open the related help article or contact Lithi.