This document describes how to configure retries for event-driven Cloud Run functions.
As described in Retry events, when a Pub/Sub message destination can't acknowledge a message, the default Pub/Sub response is to send the message again with an exponential backoff delay. An exponential backoff lets you add progressively longer delays between retry attempts. But this might not be the behavior you want for your particular implementation.
The retries property is not implemented on the function itself but on the Eventarc trigger that invokes the function, which provides more flexibility. This means that for Cloud Run destinations (including Cloud Run functions created with either the Cloud Run Admin API or the Cloud Functions v2 API), you can configure a single delivery attempt with no retries. This is the default configuration when you create an Eventarc trigger in the Google Cloud console from the Cloud Run page. For more information, see Create triggers with Eventarc.
Why event-driven functions fail to complete
An event-driven function might fail to successfully complete due to errors thrown in the function code itself. The reasons this might happen include:
- The function contains a bug and the runtime throws an exception.
- The function cannot reach a service endpoint, or times out while trying to do so.
- The function intentionally throws an exception (for example, when a parameter fails validation).
- A Node.js function returns a rejected promise, or passes a non-
nullvalue to a callback. - On rare occasions, a function might exit prematurely due to an internal error, and by default, the function might or might not be automatically retried.
In any of these cases, the function will stop executing and return an error. Event triggers producing the messages have retry policies that you can customize to meet the needs of your function.
Configure the retry policy
Depending on the needs of your Cloud Run function, you might want to configure the retry policy through the Pub/Sub subscription retry policy associated with your Eventarc trigger. This would allow you to set up any combination of the following:
- Shorten the retry window from 7 days to as little as 10 minutes.
- Change the minimum and maximum backoff time for the exponential backoff retry strategy.
- Change the retry strategy to retry immediately.
- Configure a dead-letter topic.
- Set a maximum and minimum number of delivery attempts.
To configure the retry policy:
- Write an HTTP function.
- Use the Pub/Sub API to create a Pub/Sub subscription, specifying the URL of the function as the target.
See the Eventarc documentation on retrying events for additional best practices, such as making event-driven functions that can be retried idempotent.
See the Pub/Sub documentation on handling failures for more information on configuring Pub/Sub directly.
Best practices
This section describes best practices for using retries.
Use retry to handle transient errors
Because your function is retried continuously until successful execution, permanent errors like bugs should be eliminated from your code through testing before enabling retries. Retries are best used to handle intermittent or transient failures that have a high likelihood of resolution upon retrying, such as a flaky service endpoint or timeout.
Set an end condition to avoid infinite retry loops
It is best practice to protect your function against continuous looping when using retries. You can do this by including a well-defined end condition, before the function begins processing. Note that this technique only works if your function starts successfully and is able to evaluate the end condition.
An effective approach is to discard events with timestamps older than a certain time. This helps to avoid excessive executions when failures are either persistent or longer-lived than expected.
For example, this code snippet discards all events older than 10 seconds:
Node.js
Python
Go
Java
C#
Ruby
PHP
Distinguish between functions that can be retried and fatal errors
If your function has retries enabled, any unhandled error will trigger a retry. Make sure that your code captures any errors that shouldn't result in a retry.
Node.js
Python
Go
Java
C#
Ruby
PHP
Next steps
- Deploy a Cloud Run function
- Create triggers from Pub/Sub events
- Create triggers from Cloud Storage events
- Trigger functions from Pub/Sub using Eventarc
- Trigger functions from Cloud Storage using Eventarc