Runway task failure codes: which to retry, which not to

Runway says never retry SAFETY or ASSET.INVALID failures, retry INTERNAL ones with a delay. The same triage on Sume: 429 with retry-after, new keys for runs.

4 min readSume
All posts

Runway's task-failure guidance splits by failureCode: do not retry SAFETY and ASSET.INVALID failures, and retry INTERNAL ones only after a delay. The same discipline works on Sume: back off on 429 using retry-after, and retry a failed Format run with a new Idempotency-Key.

Runway facts are from its Dev docs, read 2026-10-01. Sume facts are from Errors and credits and Format run errors.

Which Runway failure codes should I not retry?

SAFETY.INPUT.* and SAFETY.OUTPUT.* mean content moderation rejected an input or the output; the docs say not to retry. They also warn the third part of the code is diagnostic only and may not match the input (a SAFETY.INPUT.TEXT can occur with no prompt text), so do not show it to end users as fact. INPUT_PREPROCESSING.SAFETY.TEXT and ASSET.INVALID are also no-retry: the first is a rejected prompt, the second a problem with the dimensions, duration or other properties of the media you sent.

Runway retry guidance per failure code, read 2026-10-01.
failureCodeRetry?
SAFETY.*No
INPUT_PREPROCESSING.SAFETY.TEXTNo
ASSET.INVALIDNo, fix the input
INTERNAL.BAD_OUTPUT.*May retry, after correcting the prompt
INPUT_PREPROCESSING.INTERNALMay retry, with a delay
THIRD_PARTY.UNAVAILABLENot immediately; wait, then may retry
INTERNAL or nullMay retry, with a delay

What does retry-with-delay mean in practice?

For HTTP errors, Runway's docs say 429, 502, 503 and 504 may be retried, using exponential backoff plus jitter of up to 50% of the delay. Its SDKs retry automatically. A task that finishes as failed is a different layer from a request that errors, so apply the per-code table above to failureCode and the backoff rule to HTTP status.

How does Sume's retry rule compare in shape?

Sume's docs say to back off when you receive 429, use retry-after when present, and not to retry unsafe submit requests without an Idempotency-Key. For Format runs, the error page says to retry a failed run with a new Idempotency-Key, because the old one is bound to the receipt you already have; and that the error set is open, so handle known codes and fall through on the rest. See Retry-After on 429 and idempotency keys.

What should my retry code branch on?

Branch first on whether the cause is your input (fix it, do not loop) or a transient condition (wait, then retry once or twice). Cap attempts, log the code, and never retry a request that could bill again without a key that makes the repeat safe.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume