Événements de nouvelle tentative

Eventarc Standard accepte la distribution d'événements 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 au transport Pub/Sub sont automatiquement créés pour vous. (Les événements 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 le renvoie 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 à un minimum de 10 secondes et augmente à chaque échec suivant, jusqu'à un maximum de 600 secondes. Eventarc définit la durée de conservation par défaut des messages 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 la gestion des nouvelles tentatives

Si un message d'événement ne peut pas être distribué correctement pendant la période de conservation des messages, il est supprimé, sauf si un file d'attente de lettres mortes est configuré. Une file d'attente de lettres mortes vous permet de stocker et d'analyser les échecs persistants. Dans ce document, consultez la section Sujets de lettres mortes.

En raison de la diffusion "au moins une fois", votre gestionnaire d'événements peut recevoir des événements en double. Nous vous recommandons de concevoir vos gestionnaires de manière idempotente. Dans ce document, consultez Gestionnaires d'événements idempotents.

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 de l'abonnement, commencez par identifier 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 d'abonnement, consultez Propriétés d'abonnement. Pour en savoir plus sur les limites d'abonnement, consultez la page Limites de ressources dans Pub/Sub.

Identifier l'abonnement

Pour identifier l'abonnement Pub/Sub associé à votre déclencheur Eventarc, procédez comme suit :

gcloud eventarc triggers describe TRIGGER_NAME \
    --location=LOCATION

  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 state show google_eventarc_trigger.default

# 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"
        }
    }
}

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://eventarc.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://eventarc.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME" | Select-Object -Expand Content

{
  "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 de l'abonnement Pub/Sub associé à votre déclencheur Eventarc, procédez comme suit :

gcloud pubsub subscriptions update SUBSCRIPTION_ID \
    --min-retry-delay=MIN_RETRY_DELAY \
    --max-retry-delay=MAX_RETRY_DELAY

resource "google_pubsub_subscription" "default" {
  name  = "SUBSCRIPTION_ID"
  topic = google_pubsub_topic.default.id
  retry_policy {
    minimum_backoff = "MIN_RETRY_DELAYs"
    maximum_backoff = "MAX_RETRY_DELAYs"
  }
}

{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}

cat > request.json << 'EOF'
{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
EOF

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"

@'
{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
'@  | Out-File -FilePath request.json -Encoding utf8

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID" | Select-Object -Expand Content

{
  "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.

Intervalle entre les tentatives d'envoi push

Si un abonné push envoie trop d'accusés de réception négatifs, Pub/Sub peut commencer à diffuser des messages à l'aide d'un intervalle entre les tentatives push. Lorsque Pub/Sub utilise un intervalle push, il cesse de diffuser les messages pendant une durée prédéterminée. Cette période peut être comprise entre 100 millisecondes et 60 secondes. Une fois ce délai écoulé, Pub/Sub recommence à distribuer les messages. Pour en savoir plus, consultez Délai exponentiel pour les notifications 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.