fal queue retries up to 10 times: who counts attempts on Sume

fal's docs say a queue request that fails on infrastructure is retried automatically on a new runner, up to 10 attempts, while 4XX responses are never retried and direct run() or stream() calls are not retried at all. In the Sume pages I read, retrying is the caller's job, and the Idempotency-Key is what makes a resend safe.

fal text is from its retries page and changelog; Sume text from Errors and rate limits and Errors and spend. All read 2026-10-01.

What exactly does fal retry?

Three conditions: a server error (a 503, a disconnected runner, an incomplete response, or a 504), a request timeout, and a connection error. A 4XX is never retried. Since July 8, an app can set retry_config with a budget per condition, and the total is bounded by the platform ceiling of 10 attempts.

How are retries handled on Sume?

The docs describe client behavior: back off on 429 and use retry-after; never retry unsafe submits without an Idempotency-Key. I found no statement of an automatic multi-attempt retry of a submitted job, so plan to count attempts yourself.

Why does the key matter more when you retry yourself?

With a platform-side retry, the platform tracks the attempts. With a client-side retry, a timeout can hide a request that actually arrived. Resending it with the same key lets Sume treat it as the same request; an idempotent replay costs nothing on a Format run. Details in safe submit retries.

What retry budget should I set?

Pick your own: a small count, a growing delay, and a stop on any 4xx. Honor retry_after_seconds when the error carries it. fal's 10 is its platform ceiling, not a number to copy.