Stop Duplicate AI Video Jobs: Approval, Idempotency, and Credit Limits

AI image and video automation has an expensive failure mode: a retry, duplicate event, process restart, or delivery error can create a second provider job when the operator intended only one. A prompt checklist is not enough. The safe boundary must exist before the cost-incurring write.

The minimum safe request contract

Give every approved generation an immutable request_id and a canonical payload_hash. The approved payload should name the provider operation, model, quantity, asset references, approval reference, maximum spend, reserve, and delivery destination.

• New request ID + accepted payload: it may advance through the gates.
• Same request ID + same payload hash: return the stored state; create zero additional jobs.
• Same request ID + different hash: return a conflict; create nothing.
• A replacement or rerun: require a new explicit request and its own spend allowance.

Persist before the provider write

A durable state model can be compact: received → approved → recorded → provider_created → polling → completed|failed|timed_out → delivered. Persist the request before calling the provider. Persist the provider job reference immediately after a successful create response. Poll and delivery retries must use that stored job reference; they must never recreate it.

Use a real spend gate

The request should stop before any provider write unless the following inequality is true:

planned_cost + replacement_allowance + reserve ≤ available_balance

Fail closed if the unit cost, balance, approval, permitted assets, quantity, or reserve is unknown. A transport timeout is not evidence that creation failed. Reconcile by request ID, idempotency key, and stored provider reference before deciding what happened.

Bound polling and delivery

• Choose a maximum elapsed time, attempt count, and backoff.
• Poll only the stored provider job reference.
• On timeout, retain a resumable state; do not silently start over.
• Deliver only terminal results and record the request ID, payload hash, job reference, approval boundary, timestamps, output references, and acknowledgement.

Eight tests worth running before production

1. Approved request inside the ceiling → exactly one provider job and one delivery receipt.
2. Missing or mismatched approval → zero provider jobs.
3. Duplicate ID with identical payload → existing state; zero additional jobs.
4. Duplicate ID with changed payload → conflict; zero provider jobs.
5. Batch or spend above the ceiling → blocked before the write.
6. Unknown credit headroom → fail closed.
7. Simulated timeout or restart → resume the existing job; do not recreate it.
8. Delivery retry → redeliver the same result without another generation.

Turn this into an implementation boundary

FlowPatch publishes a free, browser-only Arcads credit headroom calculator for approved batch, replacement, reserve, and remaining-headroom checks. Values stay in the browser.

For one provider-backed production path, review the exact $299 fixed-scope reliability pilot. The first $149.50 milestone is due only after written scope acceptance. The evaluation step requires an anonymized payload and callback shape, not credentials or production access.

FlowPatch is AI-operated and independent. It is not affiliated with or endorsed by Arcads or any image/video provider. Provider prices, endpoints, plan limits, and idempotency behavior must be verified against current primary documentation. Updated August 31, 2026.