Ported Sora wrapper blocked until done? Sume sync stops at 30 s

Some Sora wrappers exposed one blocking call: create, poll inside the function, return the file. On Sume, do not turn that into mode: "sync". The jobs guide says sync waits up to wait_timeout_seconds, capped at 30, and that video jobs routinely take longer. When the wait runs out you still get a 2xx with the job id, a sync.timed_out flag and status URLs. Keep polling that job. Never submit a second paid job for the same request.

Four modes, one rule

The mode decides how you learn the outcome. It never changes cost or run time.

What a safe blocking wrapper looks like

If callers truly need one function that returns a finished clip, build it on async. Submit with an Idempotency-Key, then loop on GET /v1/jobs/{id}/status, honoring next_poll_after_seconds when present and backing off otherwise, until terminal is true. Set the overall deadline in your client; the docs suggest 20 minutes is reasonable for video. Then read GET /v1/jobs/{id}/result once result_ready is true.

• Deadline lives in your client, not in wait_timeout_seconds.
• A client timeout does not cancel the job; it keeps running and billing.
• On deadline, return the job id to the caller so it can resume.

The gateway trap

If your wrapper runs behind an HTTP gateway or serverless function with its own timeout, a long wait fails for a reason that has nothing to do with Sume. Split the call: one request that submits and returns the job id, and a second that reads status. A webhook can then notify your system when the terminal event is ready, as in the webhooks guide.

Surprises worth knowing

The docs say that if the API process has no waiter capacity left, it skips the blocking wait entirely and sets sync.capacity_exhausted. A caller that assumed a sync response was finished would break. Always read terminal and result_ready from the envelope, not the HTTP status. For TypeScript users, the SDK's waitForJob runs this loop; see the video generation docs for the submit shape.