Recover partial failures in batch AI video generation by tracking each item independently, preserving accepted outputs, and assigning a recovery action from the evidence available. An undelivered item may need a new attempt, an input correction, a download retry, or investigation. Those are different actions.
Read first: understand individual job states in AI video API architecture and classify recoverable errors with AI video API error handling.
Define what “batch” means in this workflow
Here, a batch is an application-managed collection of independent video requests, such as 24 product clips. Your application groups them for scheduling, tracking, and delivery. That does not require a provider-native batch endpoint, and it does not establish that such an endpoint supports video.
At the time of review, Token360’s Batch Jobs documentation lists chat completions as its supported endpoint scope. Do not submit video-generation payloads to that API based on the word “batch.” Use the documented operation for the selected video model and manage the collection in your application unless video batch support is explicitly documented.
This distinction also prevents pricing assumptions. A client-side collection does not automatically receive a batch discount, a shared completion window, or atomic cancellation. Verify each capability separately rather than importing rules from a different product or modality.
Create a manifest that survives individual failures
Before dispatching work, create a durable manifest containing one stable item identity per intended deliverable. Keep that identity separate from submission-attempt IDs, provider job IDs, and stored output IDs. Retrying an item should not erase its earlier history.
| Manifest field | Why it matters |
|---|
| Collection ID and item ID | Connect every result to its intended deliverable. |
| Input version | Identify the prompt, reference assets, model, and validated settings. |
| Attempt history | Retain each submission outcome and correlation identifier. |
| Provider resource IDs | Observe accepted work without creating another job. |
| Output and acceptance records | Preserve usable results and review decisions. |
| Recovery action and eligibility time | Control what may happen next and when. |
Join results by identity, not arrival order. The eighth response to arrive need not belong to the eighth submitted item. If your system receives a result with an unknown identity, keep it for investigation rather than assigning it to whichever row is still empty.
The manifest is an application record, not a proposed Token360 request schema. A locally chosen item ID is not automatically accepted or searchable upstream. Store actual returned identifiers and use only documented correlation mechanisms.
Classify recovery at the item level
A useful recovery queue distinguishes at least five situations. An accepted output needs preservation. A confirmed, eligible transient failure may allow another generation attempt. An invalid input needs correction. A completed job with a retrieval problem needs output recovery. An uncertain submission needs reconciliation.
Token360’s retry guidance distinguishes temporary capacity problems from account or budget stops and warns that a timeout does not prove upstream work never started. Apply those distinctions before adding items to a retry queue. A shared error status alone is insufficient.
| Item condition | Next action | New generation now? |
|---|
| Accepted output saved | Preserve and reuse | No |
| Confirmed retry-eligible failure | Schedule a bounded new attempt under the applicable policy | Possibly, when eligible |
| Invalid or unsupported input | Correct and version the recipe | Not before correction |
| Generation completed; download failed | Recover the existing output | No automatic regeneration |
| Submission outcome unknown | Reconcile using available evidence | No blind resubmission |
Keep eligibility explicit. A transient-looking error is not an unconditional license to retry: the original attempt’s outcome, the operation’s duplicate-work risk, the retry budget, and the service’s documented behavior all matter.
A 24-item example shows why whole-batch replay is wasteful
Consider this hypothetical snapshot after an initial round of work: 18 outputs are accepted and stored; two items have confirmed failures eligible for another attempt; one has invalid input; one finished generation but failed retrieval; and two have unknown submission outcomes. These categories are mutually exclusive and total 24 items.
Only two items enter the current new-generation retry wave. The invalid item waits for correction. The retrieval item goes to a different worker. The unknown items stay in reconciliation. The 18 accepted outputs remain available.
| Category | Items | Current action |
|---|
| Accepted | 18 | Preserve |
| Retry eligible | 2 | Schedule new attempts |
| Invalid input | 1 | Correct first |
| Retrieval problem | 1 | Recover existing output |
| Unknown submission | 2 | Reconcile |
Replaying all 24 items would schedule 22 more generation submissions than this two-item retry wave. That is a comparison of planned submissions, not measured accepted jobs, charges, or savings. Some other items may later require deliberate new attempts after investigation, and the two eligible retries may themselves fail.
The snapshot’s accepted-deliverable share is 18 divided by 24, or 75%. It is not a final success rate. A later report should state its cutoff time and explain recovered, corrected, still-unknown, and deliberately abandoned items.
Schedule recovery without creating a retry storm
Use the same capacity controls for recovery work that you use for fresh submissions. If every failed item wakes at the same instant, an otherwise bounded retry policy can still produce a burst. Limit active submissions, stagger eligible work, and honor applicable server-directed waits.
Choose a fairness policy between fresh work and recovery work. A system that always prioritizes retries can starve new requests; a system that always prioritizes new requests can leave an old collection unfinished. Record the policy so operators can explain why an item is waiting.
Give each item an attempt budget and the collection an elapsed-time or operational budget. Once an item exhausts its policy, move it to an explicit review state. Repeatedly returning it to the queue without changing the cause is not recovery.
Some failures should pause more than one item. If many tasks fail because of the same invalid parameter, stop dispatching matching recipes until corrected. If a shared account limit blocks submissions, fix that condition rather than burning every item’s retry allowance. Use common-cause evidence to decide the scope of the pause.
Preserve ordering and dependencies where they matter
Independent product clips can often recover independently. A storyboard is different if a later shot uses an accepted frame from an earlier shot. In that case, model the dependency explicitly: item C may require a particular accepted output version from item B.
If B is regenerated and its selected output changes, determine whether C remains valid. Do not silently reuse a dependent clip whose reference no longer matches the approved sequence. Conversely, do not invalidate unrelated clips just because one item changed.
Keep presentation order separate from processing order. Your delivery package can list clips in storyboard order even when their jobs finish out of order. Stable item identities and explicit dependencies make that possible without requiring every generation to run serially.
The general principle also appears in AWS Lambda’s partial batch response documentation: reporting individual failures can avoid reprocessing successful messages, while FIFO processing has additional ordering constraints. That is an architectural reference, not a claim that Token360 video jobs use SQS or share Lambda’s response format.
Checkpoint outcomes before acknowledging recovery work
A recovery worker should persist its observed result and next action before treating its own queue item as handled, using the coordination guarantees available in your system. Keep updates conditional on the expected item version so an old worker cannot overwrite a newer acceptance decision.
That local checkpoint does not make a remote generation atomic with your database. A crash after upstream acceptance but before recording the job ID can still leave an unknown outcome. Preserve enough attempt evidence to reconcile that window, and do not interpret a redelivered queue message as proof that a new generation is needed.
Handle repeated completion events safely. If a webhook and a status reader both report the same completed job, they should converge on the same item record. Where more than one real job exists, retain all resource identities rather than merging them into a fictional single execution.
Decide whether the collection permits partial delivery. A catalogue team might release accepted clips while a few remain under review; a continuous storyboard may require every dependent shot before export. Record which items were included in each delivered package. If recovery later adds or replaces an asset, create a revised package manifest so the recipient can identify the change. Queue completion, provider completion, and delivery completion should remain distinct milestones, with unresolved items visible to the person responsible for closing the collection.
Test mixed outcomes before running a large collection
A local fake provider can return a controlled mixture of outcomes without generating paid videos. Test the following cases before relying on an automated recovery policy. This is a proposed validation plan; it has not been executed against Token360.
- Return results out of order and verify that item mapping remains correct.
- Mix accepted, invalid, retry-eligible, retrieval-failed, and unknown items; check their recovery queues separately.
- Redeliver an already handled completion event and verify that accepted work is preserved.
- Interrupt a worker after remote acceptance but before its local checkpoint; require reconciliation.
- Exhaust an item’s retry allowance and verify that it stops returning automatically to the submission queue.
- Change a dependency’s accepted output and inspect only the affected downstream items.
Record scheduled submissions, confirmed provider jobs, accepted assets, and unresolved items as different counts. Test that the retry selector excludes already accepted items, but also inspect what it does with unknown outcomes. Avoid a simplistic rule such as “retry everything that is not success.”
The unique contribution of this guide is the item-level recovery map, the 24-item accounting example, and the mixed-outcome test plan. The category totals and submission comparison were checked locally. No production throughput improvement, retry success rate, or cost reduction was measured.
FAQ
Should I rerun a whole video batch when some items fail?
Usually, preserve accepted outputs and classify the remaining items individually. Whole-batch replay can repeat completed work and resubmit tasks whose original outcomes are still unknown.
Does Token360’s Batch Jobs API currently accept video requests?
The documentation reviewed for this guide lists chat completions as its endpoint scope. This article describes application-managed groups of video jobs, not video support in that Batch Jobs API.
Is every failed item safe to retry?
No. Invalid inputs need correction, account problems need resolution, and uncertain submissions need reconciliation. Only eligible operations should enter a bounded retry policy.
How do I match results that arrive out of order?
Use stable item identities and stored provider identifiers. Do not assign results based on their position or arrival sequence.
Should a failed download trigger another generation?
First attempt recovery of the existing output through supported operations. The generation may have completed successfully even though retrieval did not.
When is a collection finished?
Define the completion policy explicitly: all required items accepted, an approved partial delivery, or closure with documented unresolved or abandoned items. An empty retry queue alone does not prove that every item is complete.
Read next: coordinate repeated notifications with AI video API webhooks and assess actual spend with AI video API cost optimization.
Prompt Guide
Prompt Guide
Tutorial