Firebase allows 1-hour HTTP functions; don't hold a Sume job open

Do not keep a Firebase function open waiting for a Sume video, even though the limit looks generous. Submit the job, return its id, and receive the outcome later through a webhook or a status poll. The one-hour ceiling is a limit, not a design target, and a held request fails the moment any hop in front of it gives up.

The Firebase limit comes from its HTTP functions page; the Sume modes come from the jobs docs.

The limits on each side

Why holding a request is the wrong shape

A Sume job is durable and keeps running and billing even if your caller disappears. Sume's jobs docs say a client-side timeout does not cancel the job, so you only stopped the wait. Its own MCP wait is capped at 55 seconds for the same reason: an open request dies at some edge before a long render finishes. A function that waits turns a transport hiccup into a lost job id.

A shape that fits Firebase

• Function 1 (HTTP): validate input, submit to Sume with mode webhook and your function 2 URL, store the job id, return 202 immediately.
• Function 2 (HTTP): the webhook receiver. Verify the HMAC signature, store the event, return 2xx within Sume's 10 second budget, dedupe on job_id.
• Backstop: a scheduled function that polls GET /v1/jobs/{id}/status for jobs that are still not terminal, honouring next_poll_after_seconds.
• For work you must delay or retry on your own schedule, Firebase points to Cloud Tasks; use it to trigger the poll, not to hold a connection.

Idempotency

Retry the submit itself with the same Idempotency-Key so a second attempt returns the original job instead of billing a second one. Sume also says to use job_id as the idempotency key on the receiving side. See the Sume webhooks docs for the signature scheme and the redeliver endpoint.