Workflows .subscribe() vs Sume job events: push or pull?

Cloudflare's new WorkflowInstance.subscribe() streams events for a Workflow instance, but Sume does not stream job events the same way: a Sume job is pushed to you by a signed webhook or pulled by polling. There is no SSE or WebSocket endpoint for jobs, so do not look for a Sume equivalent of .subscribe().

Sume behavior is from the Jobs and results docs; the Cloudflare entry was read 2026-09-30.

What does Workflows subscribe() do?

Cloudflare's September 15 entry says: “You can now stream Workflow instance events via WorkflowInstance.subscribe() and the GET /subscribe API endpoint.” The point is to react to workflow and step events without constant status polling. That stream covers the Workflow instance, not the Sume job that one of its steps started.

What does Sume offer instead?

Three modes exist. The default async mode returns 202 with status_url, result_url, events_url and cancel_url. Webhook mode posts job.completed, job.failed or job.canceled to your public HTTPS webhook_url. Sync, also spelled subscribe, is one bounded wait of up to 30 seconds.

Is the events endpoint a stream?

No. GET /v1/jobs/{job_id}/events is a pull snapshot of public job events, and the docs say it exposes no raw provider task ids or URLs. Read it when you want history, not as a live channel.

How should a Workflow step wait for the job?

Submit in one step and store the job id. Then receive the webhook in a Worker route and hand the result to the instance, or have a later step poll status_url and wait next_poll_after_seconds when it is present. The SDK's waitForJob does the polling for you, with a 20-minute default and a 2-second floor between polls.