A generation request times out, but the provider may still be making the images. Sending the request again could create a second job. The integration needs to recover the first job, retry under a documented idempotency guarantee, or keep the outcome unresolved until you can establish what happened.
Track requests with durable server records and atomic dispatch
Before submitting work, save enough information to recognize it after a restart:
- A local job ID and the campaign or request that owns it.
- The submitted inputs or a retrievable snapshot, including source assets, formats, and locales.
- The provider job ID and idempotency key, when the API supplies or accepts them.
- The current state, attempt history, and expected output list.
Have one worker claim the job atomically before dispatch. That prevents two local workers from submitting it together; it does not prevent a duplicate after a crash between provider acceptance and saving the response. Provider-supported idempotency addresses that separate gap. A request fingerprint helps detect changed inputs, but identical inputs can also represent an intentional second generation, so it should not replace the job's identity.
Treat timeouts as unknown acceptance and reconcile before retrying
Choose the recovery path from the provider's contract:
| What you know | Next action |
|---|---|
| You saved a provider job ID | Query that job or wait for its documented completion event. Do not submit another generation merely because polling timed out. |
| Submission timed out and the endpoint supports idempotent retries | Reuse the same key and unchanged inputs within its documented protection window. |
| Submission timed out and a client-reference lookup is supported | Look up the original request and attach the recovered provider ID to the local job. |
| No supported lookup or safe retry can establish the outcome | Mark acceptance as unknown and pause automatic resubmission. Resolve it through the provider's available records or support path; make any decision to risk a duplicate explicit. |
| The provider rejected an invalid input | Correct the input before creating another attempt. |
AWS's explanation of idempotent APIs shows why a lost response can leave a caller uncertain and how a caller-provided request ID makes a retry safe when the service honors that contract. A local retry loop cannot add this guarantee to a provider that lacks it.
For retryable responses, follow the provider's delay guidance and cap attempts and total elapsed time. Check SDK defaults too: retries in both the SDK and your worker can multiply submissions. Reserve a finite request or spending allowance before dispatch, including permitted retries, so one failing batch cannot consume the whole budget.
Handle provider callbacks and asset storage defensively
Use the documented response, polling, or callback mechanism. For signed callbacks, verify the signature before changing a job. Make repeated completion events harmless, and avoid letting a late progress event move a completed job back to running. Keep provider credentials on the server.
Record each returned artifact against its requested output. Check how long provider download URLs remain valid. If your delivery needs longer retention, copy the files into storage you control before those URLs expire, and save the resulting references on the same job.
Verify complete asset bundles before delivery
Suppose the request requires square and vertical ads in English and French. That is four expected outputs. Compare the returned format/locale pairs with that list, then decode each file and check its dimensions and format. An HTTP success response with three usable images is still an incomplete bundle.
Preserve those three results. Repair the missing item separately when the provider supports it; otherwise decide whether replacing the whole bundle is acceptable. A partial download can be useful, but label the missing output rather than presenting it as the complete request. The creative asset manifest can carry these file-level references.
Keep completion separate from publication
Keep technical completion separate from campaign approval. For a workflow that requires a reviewer, deliver the files with their brief and source references to that reviewer; use the creative approval workflow to record the decision. Do not make a provider's completion callback publish the campaign by accident.
Before connecting distribution, exercise the recovery paths: lose a submission response, restart a worker, repeat a callback, and return a bundle with one missing file. You should be able to identify the original job, avoid an unplanned second submission, and show exactly which outputs are ready.
