Google Cloud Tasks retry per task: pair it with a Sume key

Cloud Tasks can now take retry settings on each task, so one task that calls a Sume submit endpoint can have its own attempt count and backoff. Every attempt of that task must send the same Idempotency-Key; a retry then repeats the same request instead of creating a second paid job.

Cloud Tasks facts are from its release notes; Sume facts from Generation admission and Errors and credits. Both read 2026-09-30.

What did Cloud Tasks add?

The release notes list, for 30 September 2026 (v2 and v2beta3, GA): set retry parameters when creating a task, create a batch of tasks, and delete a batch of tasks. They were in Preview since 21 July 2026. The task-level retry configuration overrides the queue-level one for that task.

Which Sume errors should a retry cover?

Sume's docs say: on 429 rate_limited, back off using retry-after when present. On 429 queue_full, wait for jobs to finish or cancel queued ones, then retry with the same idempotency key. On 503 provider_capacity_exceeded, retry later with the same idempotency key unless the error says not to retry.

A 409 idempotency_conflict means the key was reused for a different operation or payload; the docs say to reuse keys only for exact retries. Do not let a task retry that one.

How do I tie a task to one key?

Pick a stable id per unit of work, for example your own order or scene id, use it as the task name or store it with the task, and send it as the Idempotency-Key header in the task's HTTP request. The key then stays the same on every delivery of that task. Do not generate a new key inside the handler on each call.

The docs recommend async submit with an idempotency key for production integrations, so the task only needs to submit and store the job_id; read the result later through the jobs endpoints. Idempotency keys for AI video APIs has the rule in detail.

How many attempts is reasonable?

That is your call; neither page gives a number. Keep maxBackoff at least as long as the retry-after you see, and stop at a count where a person should look instead. A scheduled variant of this pattern is in Cloud Run job on a schedule.