Eventarc Standard est compatible avec la diffusion d'événements de type "au moins une fois". Cela signifie que si une destination ne confirme pas la réception d'un événement, Eventarc tentera automatiquement de le renvoyer.
Les caractéristiques de nouvelles tentatives d'Eventarc Standard correspondent à celles de sa couche de transport, Cloud Pub/Sub, qui gère les échecs de traitement à l'aide d'une stratégie de nouvelles tentatives d'abonnement.
Fonctionnement des nouvelles tentatives
Lorsque vous créez un déclencheur Eventarc, le sujet et l'abonnement de transport Pub/Sub sont automatiquement créés pour vous. (Les événements provenant de sources Pub/Sub peuvent utiliser un sujet Pub/Sub existant.)
Tout ID d'abonnement créé automatiquement par Eventarc aura un format commençant par eventarc-REGION-.
Par défaut, lorsqu'une destination ne peut pas accuser réception d'un message, Pub/Sub renvoie le message avec un intervalle exponentiel entre les tentatives. Un intervalle exponentiel entre les tentatives vous permet d'ajouter des délais progressivement plus longs entre les nouvelles tentatives. Le délai par défaut commence à 10 secondes minimum et augmente à chaque échec suivant, jusqu'à un maximum de 600 secondes. Eventarc définit la durée de conservation des messages par défaut sur 24 heures.
Pour en savoir plus sur la façon dont Pub/Sub gère les nouvelles tentatives, consultez Gérer les échecs de message et Requêtes de nouvelle tentative.
Bonnes pratiques pour gérer les nouvelles tentatives
Si un message d'événement ne peut pas être distribué pendant la période de conservation des messages, il est supprimé, sauf si une file d'file d'attente de lettres mortes est configurée. Une file d'attente de lettres mortes vous permet de stocker et d'analyser les échecs persistants. Dans ce document, consultez la section Files d'attente de lettres mortes.
En raison de la distribution "au moins une fois", votre gestionnaire d'événements peut recevoir des événements en double. Il est recommandé de concevoir vos gestionnaires de manière idempotente. Dans ce document, consultez la section Gestionnaires d'événements idempotents.
Nouvelles tentatives pour les destinations Cloud Run
Si vous le souhaitez, vous pouvez configurer une seule tentative de remise sans réessai pour les destinations Cloud Run (y compris les fonctions Cloud Run). Lorsque vous créez un déclencheur Eventarc dans la consoleGoogle Cloud à partir de la page Cloud Run, il s'agit de la configuration par défaut. Sinon, lorsque vous créez un déclencheur à l'aide de la Google Cloud CLI, de Terraform ou dans la console Google Cloud depuis la page Eventarc, les nouvelles tentatives sont activées par défaut.
Nous vous recommandons de désactiver les tentatives lorsque vous développez ou testez votre code afin d'éviter les tentatives d'exécution incontrôlables qui peuvent entraîner une augmentation des coûts et de l'utilisation des ressources. À l'inverse, nous vous recommandons d'activer les nouvelles tentatives lorsque votre code est en production et de suivre les bonnes pratiques pour les gérer afin que chaque message soit traité comme prévu. Par exemple, vous pouvez transférer les messages non distribués vers un sujet de lettres mortes (également appelé file d'attente de lettres mortes), qui vous permet de stocker et d'analyser les échecs persistants.
Pour en savoir plus, consultez les guides Cloud Run suivants : Configurer les nouvelles tentatives d'exécution des fonctions basées sur des événements et Créer des déclencheurs avec Eventarc.
Configurer les nouvelles tentatives
Vous pouvez personnaliser le comportement par défaut des nouvelles tentatives. Tous les paramètres de nouvelle tentative et de conservation sont configurés via la stratégie de nouvelle tentative d'abonnement Pub/Sub associée à votre déclencheur Eventarc.
Pour modifier la stratégie de nouvelle tentative d'abonnement, identifiez d'abord l'abonnement Pub/Sub associé à votre déclencheur Eventarc. Mettez ensuite à jour l'abonnement lui-même.
Pour en savoir plus sur les propriétés des abonnements, consultez Propriétés des abonnements. Pour en savoir plus sur les limites d'abonnement, consultez Limites de ressources dans Pub/Sub.
Identifier l'abonnement
Pour identifier l'abonnement Pub/Sub associé à votre déclencheur Eventarc, procédez comme suit :
Console
Dans la console Google Cloud , accédez à la page Déclencheurs Eventarc.
Dans la liste des déclencheurs, cliquez sur le déclencheur dont vous souhaitez connaître les détails.
Cliquez sur le nom du thème.
Pour afficher l'ID de l'abonnement, cliquez sur l'onglet Abonnements.
gcloud
Vous pouvez utiliser la commande gcloud eventarc triggers describe pour récupérer l'ID de l'abonnement.
gcloud eventarc triggers describe TRIGGER_NAME \ --location=LOCATION
Remplacez les éléments suivants :
TRIGGER_NAME: nom du déclencheur ou identifiant complet.LOCATION: l'emplacement du déclencheur Eventarc.
Cette commande renvoie des informations sur le déclencheur, semblables à ce qui suit et incluant l'ID de l'abonnement :
createTime: '2023-03-16T13:40:44.889670204Z'
destination:
cloudRun:
path: /
region: us-central1
service: hello
eventDataContentType: application/protobuf
eventFilters:
...
transport:
pubsub:
subscription: projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID
topic: projects/PROJECT_ID/topics/TOPIC_ID
Terraform
Pour décrire une ressource Terraform google_eventarc_trigger, vous pouvez utiliser la commande state show.
terraform state show google_eventarc_trigger.default
La commande state show renvoie des informations sur le déclencheur, y compris l'ID de l'abonnement. Exemple :
# google_eventarc_trigger.default:
resource "google_eventarc_trigger" "default" {
conditions = {}
create_time = "2025-07-14T17:29:22.575033822Z"
effective_labels = {
"goog-terraform-provisioned" = "true"
}
...
transport {
pubsub {
subscription = "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
topic = "projects/PROJECT_ID/topics/TOPIC_ID"
}
}
}
Pour en savoir plus sur l'utilisation de Terraform, consultez la documentation Terraform sur Google Cloud .
REST
Pour décrire un déclencheur dans un projet et un emplacement donnés, utilisez la méthode projects.locations.triggers.get.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
TRIGGER_NAME: nom du déclencheur que vous souhaitez décrire.PROJECT_ID: ID de votre projet Google Cloud.LOCATION: région dans laquelle le déclencheur est créé, par exempleus-central1.
Pour envoyer votre requête, développez l'une des options suivantes :
Si la requête aboutit, le corps de la réponse contient une instance de Trigger semblable à celle-ci :
{
"name": "projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME",
"uid": "d700773a-698b-47b2-a712-2ee10b690062",
"createTime": "2022-12-06T22:44:04.744001514Z",
"updateTime": "2022-12-06T22:44:09.116459550Z",
"eventFilters": [
{
"attribute": "type",
"value": "google.cloud.pubsub.topic.v1.messagePublished"
}
],
"serviceAccount": "SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com",
"destination": {
"workflow": "projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_NAME"
},
"transport": {
"pubsub": {
"topic": "projects/PROJECT_ID/topics/TOPIC_ID",
"subscription": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
}
}
}
Modifier l'abonnement
Pour mettre à jour la stratégie de nouvelle tentative d'abonnement Pub/Sub associée à votre déclencheur Eventarc, procédez comme suit :
Console
Dans la console Google Cloud , accédez à la page Déclencheurs Eventarc.
Dans la liste des déclencheurs, cliquez sur le déclencheur dont vous souhaitez connaître les détails.
Cliquez sur le nom du thème.
Pour afficher l'ID de l'abonnement, cliquez sur l'onglet Abonnements.
Cliquez sur l'ID de l'abonnement, puis sur Modifier.
Dans la section Stratégie de réessai, sélectionnez Réessayer immédiatement.
Vous pouvez également réessayer après un intervalle exponentiel entre les tentatives en saisissant les valeurs suivantes en secondes :
Intervalle minimal entre les tentatives : délai minimal en secondes entre les envois consécutifs d'un message donné. La valeur par défaut est de 10 secondes et doit être comprise entre 0 et 600.
Intervalle maximal entre les tentatives : délai maximal en secondes entre les distributions consécutives d'un message donné. La valeur par défaut est de 600 secondes et doit être comprise entre 0 et 600.
Pour en savoir plus, consultez la Règle de réessai.
Cliquez sur Mettre à jour.
gcloud
Vous pouvez utiliser la commande gcloud pubsub subscriptions update pour mettre à jour la stratégie de nouvelle tentative d'abonnement.
gcloud pubsub subscriptions update SUBSCRIPTION_ID \ --min-retry-delay=MIN_RETRY_DELAY \ --max-retry-delay=MAX_RETRY_DELAY
Remplacez les éléments suivants :
SUBSCRIPTION_ID: l'ID de l'abonnement ou un identifiant complet.Les deux indicateurs suivants doivent être spécifiés pour réessayer après un délai de backoff exponentiel. Sinon, tout indicateur omis revient à sa valeur par défaut :
MIN_RETRY_DELAY: délai minimal en secondes entre les envois consécutifs d'un message donné. La valeur par défaut est de 10 secondes et doit être comprise entre 0 et 600.MAX_RETRY_DELAY: délai maximal en secondes entre les distributions consécutives d'un message donné. La valeur par défaut est de 600 secondes et doit être comprise entre 0 et 600.
Vous pouvez également utiliser l'option --clear-retry-policy pour effacer la règle de réessai et définir l'abonnement sur "Réessayer immédiatement".
Terraform
Vous pouvez mettre à jour une stratégie de nouvelle tentative d'abonnement Pub/Sub en configurant la ressource Terraform google_pubsub_subscription. Utilisez le bloc import pour importer l'abonnement existant afin que Terraform puisse suivre la ressource dans votre fichier d'état. Vous pouvez ensuite gérer la ressource importée comme n'importe quelle autre, en utilisant ignore_changes pour spécifier les attributs que Terraform doit ignorer lors de la mise à jour de la ressource.
Exemple :
import { to = google_pubsub_subscription.default id = "SUBSCRIPTION_ID" } resource "google_pubsub_subscription" "default" { name = "SUBSCRIPTION_ID" topic = "TOPIC_ID" retry_policy { minimum_backoff = "MIN_RETRY_DELAYs" maximum_backoff = "MAX_RETRY_DELAYs" } lifecycle { # Ignore push delivery configuration which is managed by Eventarc ignore_changes = [push_config] } }
Remplacez les éléments suivants :
SUBSCRIPTION_ID: ID de l'abonnement.TOPIC_ID: ID de la rubrique.MIN_RETRY_DELAY: délai minimal en secondes entre les envois consécutifs d'un message donné. La valeur par défaut est de 10 secondes et doit être comprise entre 0 et 600.MAX_RETRY_DELAY: délai maximal en secondes entre les distributions consécutives d'un message donné. La valeur par défaut est de 600 secondes et doit être comprise entre 0 et 600.
REST
Pour mettre à jour la règle de réessai d'un abonnement dans un projet donné, utilisez la méthode projects.subscriptions.patch.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
MIN_RETRY_DELAY: délai minimal en secondes entre les envois consécutifs d'un message donné. La valeur par défaut est de 10 secondes et doit être comprise entre 0 et 600.MAX_RETRY_DELAY: délai maximal en secondes entre les diffusions consécutives d'un message donné. La valeur par défaut est de 600 secondes et doit être comprise entre 0 et 600.PROJECT_ID: ID de votre projet Google Cloud.SUBSCRIPTION_ID: ID de l'abonnement Pub/Sub que vous mettez à jour.
Corps JSON de la requête :
{
"subscription": {
"retryPolicy": {
"minimumBackoff": "MIN_RETRY_DELAYs",
"maximumBackoff": "MAX_RETRY_DELAYs"
}
},
"updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
Pour envoyer votre requête, développez l'une des options suivantes :
Si la requête aboutit, le corps de la réponse contient une instance de Subscription semblable à celle-ci :
{
"name": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID",
"topic": "projects/PROJECT_ID/topics/TOPIC_ID",
...
"retryPolicy": {
"minimumBackoff": "MIN_RETRY_DELAYs",
"maximumBackoff": "MAX_RETRY_DELAYs"
},
"state": "ACTIVE"
}
Autres points à prendre en compte concernant les nouvelles tentatives
Vous devez tenir compte des points suivants lorsque vous gérez les échecs de traitement ou que vous transférez les messages non remis.
Report de l'envoi
Si un abonné push envoie trop d'accusés de réception négatifs, Pub/Sub peut commencer à distribuer les messages à l'aide d'un intervalle entre les tentatives push. Lorsque Pub/Sub utilise un intervalle exponentiel entre les tentatives d'envoi, il cesse de distribuer les messages pendant une durée prédéterminée. Cette période peut aller de 100 millisecondes à 60 secondes. Une fois le délai écoulé, Pub/Sub recommence à distribuer les messages. Pour en savoir plus, consultez Backoff de push.
Files d'attente de lettres mortes
Si la destination ne reçoit pas le message, vous pouvez transférer les messages non distribués vers une file d'attente de lettres mortes (également appelé sujet de lettres mortes). Une file d'attente de lettres mortes peut stocker des messages que la destination ne peut pas confirmer. Vous devez définir une file d'attente de lettres mortes lorsque vous créez ou mettez à jour un abonnement Pub/Sub, et non lorsque vous créez un sujet Pub/Sub ou lorsque Eventarc crée un sujet Pub/Sub. Pour en savoir plus, consultez Configurer une file d'attente de lettres mortes.
Erreurs qui ne justifient pas de nouvelles tentatives
Lorsque les applications utilisent Pub/Sub comme source d'événements et que l'événement n'est pas diffusé, l'événement est automatiquement relancé, sauf pour les erreurs qui ne justifient pas de nouvelles tentatives. Les événements d'une destination Workflows, quelle que soit leur source, ne seront pas relancés si le workflow ne s'exécute pas. Notez que Workflows accuse réception des événements dès le début de l'exécution du workflow. Si l'exécution du workflow démarre, mais échoue ultérieurement, elle n'est pas relancée. Pour résoudre ces problèmes de service, vous devez gérer les erreurs et les nouvelles tentatives dans le workflow.
Dupliquer des événements
Des événements en double peuvent être distribués aux gestionnaires d'événements. Selon la spécification CloudEvents, la combinaison des attributs source et id est considérée comme unique. Par conséquent, tous les événements ayant la même combinaison sont considérés comme des doublons. Nous vous recommandons de mettre en œuvre des gestionnaires d'événements idempotents.
Gestionnaires d'événements idempotents
Les gestionnaires d'événements qui peuvent être relancés doivent être idempotents, en suivant les consignes générales suivantes :
- De nombreuses API externes vous permettent de fournir une clé d'idempotence en tant que paramètre. Si vous utilisez une telle API, vous devez utiliser l'ID d'événement comme clé d'idempotence.
- L'idempotence fonctionne bien avec une livraison de type "au moins une fois", car elle permet de répéter la tentative en toute sécurité. Une bonne pratique pour écrire du code fiable consiste donc à combiner l'idempotence à la répétition des tentatives.
- Assurez-vous que votre code est idempotent en interne. Exemple :
- Assurez-vous que les mutations peuvent se produire plus d'une fois sans en changer le résultat.
- Interrogez l'état de la base de données dans une transaction avant de muter l'état.
- Assurez-vous que tous les effets secondaires sont eux-mêmes idempotents.
- Imposez un contrôle transactionnel en dehors de votre service, indépendamment du code. Par exemple, conservez l'état quelque part en notant qu'un ID d'événement donné a déjà été traité.
- Gérez les appels de doublons hors bande. Par exemple, mettez en place un processus de nettoyage distinct qui se lance après les appels de doublons.