Eventarc Standard supports at-least-once event delivery. This means that if a destination fails to acknowledge an event, Eventarc will automatically attempt to redeliver it.
The retry characteristics of Eventarc Standard match that of its transport layer, Cloud Pub/Sub, which handles processing failures by using a subscription retry policy.
How retries work
When you create an Eventarc trigger, the Pub/Sub
transport topic and subscription are automatically created for you. (Events from
Pub/Sub sources can use an existing Pub/Sub topic.)
Any subscription ID automatically created by Eventarc will have a
format that begins with eventarc-REGION-.
By default, when a destination can't acknowledge a message, Pub/Sub will send the message again with an exponential backoff delay. An exponential backoff lets you add progressively longer delays between retry attempts. The default delay starts at a minimum of 10 seconds and increases with each subsequent failure, up to a maximum of 600 seconds. Eventarc sets the default message retention duration to 24 hours.
For more information about how Pub/Sub handles retries, see Handle message failures and Retry requests.
Best practices for handling retries
If an event message can't be successfully delivered within the message retention window, it's discarded unless a dead-letter topic is configured. A dead-letter topic lets you store and analyze persistent failures. In this document, see Dead letter topics.
Because of at-least-once delivery, your event handler might receive duplicate events. It's a best practice to design your handlers to be idempotent. In this document, see