fal generation_timeout 504 error: what to do on Sume

On fal, generation_timeout is a 504 error type returned when the operation took longer than the allowed time. Sume documents an error category with the same name, and its action is: poll status or retry later.

fal details are from its Model Errors page; Sume details from Errors and credits, read 2026-10-01.

What does the fal error look like?

The fal page describes a structured response: an HTTP status code, headers such as X-Fal-Needs-Retry, and a JSON body with a detail array. Each object carries loc, msg, type and url, with optional ctx and input. For generation_timeout the status is 504, the type is generation_timeout, and the page marks it retryable as true or false.

The same page tells clients to use type for conditional logic and not to parse msg.

What is Sume's generation_timeout?

Sume's errors page lists error categories with a recommended action. generation_timeout and worker_timeout both say: poll status or retry later. Compare that with internal, which says to inspect events and contact support with the request or job id.

Why poll before retrying?

The job status vocabulary is queued, processing, completed, failed, canceled. A timeout category can describe a job whose state you can still read, so check GET /v1/jobs/:id/status first. Only when it is terminal and failed does a new attempt make sense, and then a paid retry needs its own deliberate Idempotency-Key; see failed run retry needs a new key.

How do I port fal error handling?

Switch on the error category rather than the HTTP status alone. Map fal's type-based branching to Sume's category: poll for the two timeout categories, retry with the same idempotency key for queue, and escalate with ids for internal. The two vendors name things alike, but the Sume docs define the action; do not assume fal's retryable flag carries over.