Cloud Tasks brings per-task retry settings to general availability

A background job that refreshes an incident summary and a historical export should not necessarily keep trying for the same length of time. Google Cloud’s September 30 release notes mark task-level retry settings in Cloud Tasks as generally available, alongside batch creation and deletion. An individual task can now override its queue’s retry configuration when it is created.

At review time, Google’s product-specific release page still showed the earlier preview entry, while the central release notes and task-creation guide reflected the new release. The deployed client library also needs to expose the new fields. This report verifies documentation, not a hands-on rollout.

Cloud Tasks delivers queued work to a handler, such as an HTTP endpoint that gathers evidence for an incident assistant. The retry configuration determines how the queue tries again after an unsuccessful attempt. Putting that choice on the task is useful when jobs share infrastructure but have different useful lifetimes: a summary requested during an active incident may become stale long before a routine historical export loses its value.

The exception can travel with the job

The configuration guide shows a retryConfig object in the task-creation request. It controls attempts, retry duration and backoff, the waiting period between attempts. maxAttempts includes the initial attempt. This is an override of queue retry behavior, not a replacement for the application’s decision about whether the requested work still makes sense.

One detail deserves attention before translating a business deadline into configuration. Google documents that retrying stops after both the attempt and duration conditions are met, or when the task succeeds; retention limits also apply. Treating those fields as “whichever limit arrives first” would produce the wrong expectation. For a job that must not act after a particular time, the handler needs to inspect an application deadline before doing the work.

For example, consider a hypothetical task asking an assistant to assemble current checkout errors for an incident update. Give the request an incident identifier and an expiry time. If the dependency is temporarily unavailable, another attempt may still deliver a useful summary. If the request has expired by the time the handler runs, it should record that disposition and finish without producing a fresh-looking report from an obsolete request. The expiry check belongs to this proposed application design; it is not a new Cloud Tasks feature.

When a retry repeats a completed change

That distinction becomes more consequential when the job can change a system. A handler might apply a configuration update and lose its response before the queue learns that it finished. Google’s execution limitations explicitly allow duplicate execution, so a shorter retry policy does not make a write happen exactly once.

After a configuration update loses its response, the next handler needs to reconcile that attempt with the target’s current state. A stable operation identifier lets it find a completed change rather than apply it again. When another executor can perform the same remediation, the duplicate check has to cover that executor too. This applies the bounded-action approach in the auto-remediation guide to a specific delivery mechanism.

For a read-only evidence refresh, repeating the query may be acceptable, subject to its cost and freshness. For a write whose prior outcome cannot be established, another automatic attempt can compound the uncertainty. Preserve the unresolved result for investigation instead of treating the queue’s willingness to retry as evidence that repetition is safe.

Per-task settings let an incident summary and a historical export share a queue without giving both the same retry lifetime. The summary handler still needs its expiry check so a late delivery does not produce an obsolete report. If a job changes configuration, its handler also needs to establish whether an earlier attempt completed before deciding whether another write is needed. If the outcome remains unknown, preserve it for investigation. Those application checks determine whether another delivery can still accomplish the requested work.