Cloud Tasks retries can follow each job’s useful life

A historical export can arrive hours late and still be worth opening. An incident update may arrive just as accurately after everyone has moved on. Put both in the same queue and one retry policy has to accommodate two very different ideas of “still useful.”

Google’s September 30 release notes announced general availability for task-level Cloud Tasks retry configuration, alongside batch creation and deletion. A newly created task can override its queue’s retry defaults. At the original review, the central notes and creation guide reflected the release while the product-specific release page still listed preview; client libraries also needed to expose the fields. This article explains the documentation, not a deployment tested here.

Give the incident update an expiry of its own

Cloud Tasks delivers a job to a handler, perhaps an HTTP endpoint that assembles the update. If the attempt fails, retry settings govern another delivery. The task-creation request accepts retryConfig with attempt, duration and backoff settings. Backoff is the wait between attempts, and maxAttempts counts the first attempt too.

The stopping rule matters to the person expecting that update: Google documents stopping when both attempt and duration conditions are met, or the task succeeds, with retention limits also applying. Reaching one configured limit does not simply mean the job is finished retrying.

For an imagined incident-summary handler, include the incident identifier and an expiry time. A brief outage might delay a still-useful summary; a later delivery might describe a phase the team has already left behind. Let the handler recognize that stale job before assembling it. Retry duration controls queue behavior. The application has to decide when this particular answer is no longer wanted.

The reply was lost. Was the change lost too?

Now give the handler a job that changes configuration. Imagine it applies the change, but its reply is lost before the queue learns that it finished. The job comes back. Google’s execution limitations permit duplicate execution; fewer retries cannot turn the completed change into an exactly-once operation.

The returning delivery needs to find out what the earlier one did. A stable operation identifier can connect them, allowing the handler to compare the recorded operation with the target’s current state. If another executor can make the same remediation, include it in that duplicate check. The auto-remediation guide applies this reconciliation principle to automated changes.

Rerunning a read-only summary query may be acceptable while its cost and freshness fit. Repeating a write with an unknown outcome is different: it can make a second change before anyone understands the first. Leave that result marked uncertain and investigate it. A redelivered request is not a decision that the operation should happen again.

Task-level settings let the short-lived update and the patient historical export share infrastructure without sharing every retry choice. When either arrives, the handler still has two practical questions to answer: does anyone still want this job, and has an earlier attempt already done it?