Prevent duplicate AI generation jobs during provider failures
How to prevent duplicate AI generation jobs during provider failures using idempotency, ambiguous-outcome handling, provider request IDs, sticky polling, and reconciliation.
Preventing duplicate AI generation jobs is not the same as adding a generic retry loop. The failure that matters is an ambiguous outcome: your client or router timed out, dropped a connection, or never received a provider acknowledgment, so you cannot tell whether a billed generation already started. Blindly submitting again can create a second paid job for the same intent. The useful contract is cross-provider duplicate prevention—keep one logical generation identity, stick to the provider request that may already exist, and reconcile before any alternate route is considered.
Industry API design treats that ambiguity as a first-class case. Stripe’s idempotent-request documentation explains why create and update calls need an idempotency key after connection errors: retries should return the original result instead of performing the operation twice. The IETF HTTPAPI Idempotency-Key draft uses the same timeout story for POST: the client cannot tell whether the resource was created, so the server must recognize retries of the same request. Those sources describe the pattern; they are not OfflineCreator product guarantees.
OfflineCreator’s documented router answer is operational rather than promotional. If submission may have succeeded, Studio reconciles that attempt instead of launching a second paid generation. Reliability work is framed as something that should not create surprise charges or duplicate jobs. This page owns that cross-provider duplicate-prevention contract. Command-level CLI safe-retry behavior belongs elsewhere, and the parent AI Router hub owns the broader generation-router query.
- Ambiguous outcome
- No definitive provider responseTimeouts and dropped connections can hide a successful submit; treat them as reconcile-first, not retry-first.
- Idempotent intent
- One logical generationExternal APIs use idempotency keys so retries replay results instead of creating a second side effect.
- Cross-provider scope
- Router-owned, not CLI-ownedThis URL covers sticky provider identity and reconciliation across routes; CLI command retries are a different ownership boundary.
Failure mode: timeout after dispatch without a second paid submit
Consider a concrete path the hub overview does not spell out as a walkthrough. A signed quote reserves credits for one Seedance text-to-video request. The router selects a configured direct provider, persists the attempt, and submits. The HTTP client then times out. From the caller’s point of view the job looks failed. From the provider’s point of view the generation may already be running under a request ID the router stored. The duplicate-prevention decision is to stay sticky to that request ID, poll it, and reconcile terminal status and actual cost—not to fan out immediately to fal or another standby route as if the first submit never happened.
That is the boundary with provider failover. Failover pages own when a definitive rejection or terminal failure makes an alternate route eligible inside the locked envelope. This page owns the prior question: whether a second generation is allowed at all when the first outcome is still ambiguous. Cloud routing does not erase disclosure either. OfflineCreator’s live provider page states that Studio still sends generation inputs to the provider serving the selected model, that the current launch catalog is routed through fal, and that LocalForge is the offline option when inputs cannot leave the machine.
- Timeout after dispatch
- Ambiguous, not definitiveDo not treat a missing response as proof that no provider job exists.
- Sticky next step
- Poll the stored request IDStatus retrieval stays on the original attempt until reconciliation completes.
- Cloud boundary
- Disclosed provider processingDuplicate prevention changes attempt handling; it does not convert the job into LocalForge offline inference.
Idempotency, ambiguous outcomes, request IDs, sticky polling, and reconciliation
Evaluate duplicate prevention with five evidence checks that fail differently. Idempotency asks whether a logical operation can be retried without creating a second side effect. Ambiguous outcomes ask what the system does when the network fails without a provider response. Provider request IDs ask whether the submitted attempt has a durable identity. Sticky polling asks whether status retrieval stays on that same provider attempt instead of opening a new job. Reconciliation asks how actual cost, terminal status, and incomplete submits are recorded without raising a reserved customer charge.
OfflineCreator’s first-party routing notes describe that path in product language: persist the selected provider and attempt around submission, keep polling sticky to the provider request ID, allow at most one alternate attempt only after a definitive pre-submit rejection that is safe to retry or a terminal failed job, and record ambiguous network failures for reconciliation instead of a duplicate submit. Every attempt is documented to store route, request ID, quote, actual cost, latency, status, and sanitized error metadata, with provider-reported actual cost reconciled after completion. The AI Router FAQ adds that the customer quote is signed and reserved before submission and that any safe alternate must stay inside the locked cost envelope.
Community research in the last-30-days pass reinforces why the ambiguous case is hard, without proving product outcomes. An August 2026 arXiv paper on verified tool calls frames non-atomic failures—timeouts after dispatch, delayed visibility, partial updates—as drivers of duplicate agent actions, and studies wrappers that combine postcondition checks, verify-before-retry logic, and idempotency keys in simulation. Treat that paper as qualified third-party evidence about the failure class, not as a benchmark of OfflineCreator uptime, savings, or media quality.
- Idempotency
- Retry without a second side effectKeys or equivalent server memory let clients repeat a request after transport failure.
- Ambiguous outcomes
- Reconcile before alternate submitNo provider response is not proof the job never started.
- Provider request IDs
- Durable attempt identityPersist the selected route and provider request identity around submission.
- Sticky polling
- Status on the same attemptPoll the recorded provider request ID instead of opening a parallel generation.
- Reconciliation
- Close the ledger without a second chargeRecord terminal status and actual cost against the reserved quote envelope.
Where to go next in the AI Router set
If you need the broad product overview—stable model IDs, signed quotes, and the booking metaphor—start at the parent AI Router page. Stay here when the blocker is duplicate paid generations under ambiguous provider failures.
If your next question is when an alternate route may run after a definitive failure, continue to AI API provider failover. If you need the signed quote payload and reservation lifecycle before credits move, continue to signed AI generation quotes. If you need the price-lock step that precedes submission, continue to lock AI generation price before running. Keep those as next actions rather than repeating the hub’s broad query on this URL.
Canonical ownership and evidence boundary
This URL owns cross-provider duplicate prevention for the query “prevent duplicate ai generation jobs,” covering idempotency framing, ambiguous outcomes, provider request IDs, sticky polling, and reconciliation. CLI safe retry owns command-level retry behavior. Provider failover owns alternate-route eligibility after definitive failures. The /ai-router hub owns the broad AI generation router query. Do not expand this page into a second hub or a generic HTTP retry tutorial.
Supported product statements here are limited to OfflineCreator’s documented router and provider-routing behavior verified against first-party repository sources, plus the live cloud provider disclosure. Supported external statements are limited to Stripe’s idempotent-request documentation, the IETF Idempotency-Key draft, and the qualified arXiv tool-call reliability paper. This draft does not assert live production availability of every managed route, does not publish wholesale rate cards as customer guarantees, and does not invent privacy, retention, benchmark, or outcome claims.