Durable Object waitUntil keep-alive and a Sume job poll

Yes, a Durable Object can now keep working on a submitted job after its client disconnects, but a Sume video job does not need the object to stay alive at all. The job runs on Sume. Store the job id, poll status_url honoring next_poll_after_seconds, or take a webhook, and treat the object's wait as one pollable step.

Cloudflare facts are from its changelog entry; Sume facts from Jobs and results and the SDK run docs, read 2026-09-30.

What did Cloudflare change?

Durable Objects previously stayed active while handling a request from a connected client. The change covers the case with no connected client, such as an agent that continues a submitted job after the client disconnects. Pending service binding requests, pending calls to another Durable Object, this.ctx.waitUntil() promises and pending setTimeout() calls now keep the object running. It is the default for a compatibility date of 2026-10-01 or later, or opt in with durable_object_io_tasks_prevent_eviction.

The changelog text I read does not state a time limit, so check the changelog itself for any per-operation cap before you design around one.

Why not hold one long operation for the whole job?

A video job can run for minutes, and the docs say the wait "lives in **your** client, so its timeout can be minutes" without holding an HTTP request open. sync mode is capped: wait_timeout_seconds never exceeds 30. Long waits are a poll loop, not a request.

What should the object store?

The job id and the Idempotency-Key you used. If the object is evicted or restarts mid-poll, resume from status_url. Never submit a new paid job for the same intent; a retried submit with the same Idempotency-Key returns the original job instead of billing a second one.

A timeout in your code does not cancel the job. It keeps running and billing, so persist the id and either resume or cancel explicitly. Related Workers patterns: Workflows subscribe vs Sume job events.

Does a 20-minute waitForJob fit inside one wait?

Don't assume so. waitForJob defaults to a 20-minute client-side deadline and throws SumeJobTimeoutError when exceeded. Since I cannot confirm from the snapshot how long one pending operation may keep an object alive, run the poll as short steps that each persist progress rather than one 20-minute promise.