​

Rerunning Connected Order Chains

This guide explains how full-chain reruns work and when to use triggerFullChain on the Rerun Order endpoint.

​

One order vs. the whole chain

Some Ollang order types depend on the output of other orders. These dependencies form a chain:

• A child (or dependent) order produces the input another order needs.
• A parent order consumes the output of its child.

Examples of connected chains: A standard rerun (triggerFullChain: false, the default) reprocesses only the selected order, reusing the existing results of its dependencies. Use this when only the selected stage needs to be regenerated. A full-chain rerun (triggerFullChain: true) resets the complete connected chain and reprocesses every stage in dependency order: the deepest dependency runs first, and the requested order is regenerated last using the freshly produced outputs. Use this when the improvement needs to flow through the whole pipeline — for example, a better Text for AD transcription that should feed a new Audio Description.

​

How processing order is determined

The API walks the requested order’s dependency links downward to its earliest required child, resets every order in the chain, and re-triggers the pipeline from the bottom up:

• Audio Description rerun → regenerates Text for AD first, then produces the new Audio Description from the new text.
• AI Dubbing rerun → regenerates Closed Captioning, then the Subtitle, then the dub.
• Subtitle rerun → regenerates Closed Captioning first, then the Subtitle.
• A standalone order with no dependencies simply reruns itself.

Only the requested order’s own chain is affected — orders from other language pairs or unrelated orders in the same project are never touched, and no order above the requested one (its parents) is rerun. If a parent stage also needs regeneration, rerun the parent order itself with triggerFullChain: true.

​

What happens to existing results

All AI-generated outputs of every order in the chain are discarded and regenerated. Source materials are preserved. Review gates configured on the workflow are honored again during the rerun.

​

Monitoring

The response’s triggeredOrderIds lists every order that was triggered, from the requested order down to its deepest dependency. Poll Get Order for each returned ID to track progress. The requested order completes last.

​

Credit consumption

Existing account-level rerun exemptions still apply per order — free-rerun clients and daily free-rerun quotas are honored exactly as they are for single-order reruns. If the chain’s total cost exceeds your available balance or monthly spend limit, the request fails before anything is reset or charged.

​

Limitations and error conditions

• The requested order must be a completed (or stalled) Level 0 order of a supported type — the same eligibility rules as a standard rerun.
• Full-chain reruns are supported for video pipelines (CC, Subtitle, AI Dubbing, Audio Description) and document orders. Other order types return a validation error: Full-chain rerun is not supported for order type: ....
• If any stage of the chain is currently being processed, the request is rejected with Order chain is already being processed — wait for the chain to finish first.
• If a connected dependency is missing (e.g. a Subtitle order with no CC order), the request is rejected with Connected dependency chain is incomplete.
• All validation happens before any order is touched: a rejected request never leaves the chain partially reset and never produces a partial charge.

​

Recommendation

Use triggerFullChain: false (or omit the field) when only the selected stage needs to be regenerated. Reserve triggerFullChain: true for cases where the upstream stages must also be reprocessed — it consumes more credits and takes longer to complete.