Cloud Tasks batch create is GA: one Sume idempotency key per task
Cloud Tasks batch create went GA on Sep 30, 2026. Give every task its own Sume Idempotency-Key so a batch retry never doubles a paid generation.

When you enqueue Sume generations with the new Cloud Tasks batch create, put a distinct Idempotency-Key header on each task, derived from the business item and not from the batch. Google's release notes list batch create, batch delete and per-task retry parameters as generally available on September 30, 2026. A batch call that fails halfway is easy to repeat, and stable per-item keys are what make the repeat safe.
What Google shipped
From the Cloud Tasks release notes:
| Feature | Status | Why it matters for Sume |
|---|---|---|
| Batch create tasks | GA, Sep 30 2026 | Enqueue many generations in one call |
| Batch delete tasks | GA, Sep 30 2026 | Drop pending items after a campaign is cancelled |
| Per-task retry parameters | GA, Sep 30 2026 | Different back-off for paid and free calls |
Why the key belongs to the item
Cloud Tasks delivers at least once, so a handler can run twice. Sume's rule is simple: the same key with the same body returns the original job, and the same key with a different body returns 409 idempotency_conflict. If the key came from the batch, a re-created batch would collide on unrelated items. If it came from a random value generated in the handler, a retry would get a new key and a second paid job.
A key such as campaign-42-item-7-v1 survives handler retries, batch re-creation and operator re-runs. Change the version suffix only when you truly want a new generation.
Match retry parameters to Sume's errors
Per-task retry parameters let you set different limits per task. Sume's responses split cleanly:
- 429
rate_limited: retry, honouring retry-after. - 429
queue_full: retry with a longer minimum back-off, because your queue capacity ismax(3, 5 times concurrency). - 402
insufficient_credits: return a non-retryable status from the handler so the task is not re-sent. - 202 accepted: store the job id and return success; the job continues without the task.
Do not wait inside the task handler
The handler should create the job and return. Sume's sync and subscribe modes wait at most 30 seconds through wait_timeout_seconds and then ask you to poll. A client timeout does not cancel the job, so never resubmit after one. Use webhook mode and process job.completed separately, or poll /status with next_poll_after_seconds.
If you have up to 100 items of one Format, bulk-runs is a single call with a concurrency setting. Cloud Tasks is the better fit when items arrive over time or need different schedules.
Sources
Related posts
More in Developers
- Cloudflare Worker roles: let an agent deploy a Sume webhook receiver
Cloudflare's four Worker roles let an agent token deploy a Sume webhook receiver without delete rights. Which role to give it and what Sume still needs.
- Cloudflare Queues limits vs Sume queue_full 429: who retries?
Cloudflare Queues allows 100 retries and 24h delaySeconds. Sume answers 429 queue_full or rate_limited. How to back off in a consumer without duplicate jobs.
- Cloudflare Stream 200 MB upload limit: when you must use tus
Cloudflare Stream accepts basic uploads up to 200 MB and requires tus above that. Read the size from a Sume probe and route the file before you upload.
- Cloudflare Workflows step.sleep and a Sume job: poll without steps
Cloudflare Workflows step.sleep does not count toward the step limit, so a Sume job poll loop can wait cheaply. Limits, a loop shape and the retention catch.
Written by Sume