Les nouvelles caractéristiques d'Eventarc correspondent à celles de sa couche de transport, Cloud Pub/Sub. Pour en savoir plus, consultez les sections Requêtes de nouvelle tentative et Intervalle entre les tentatives push.
La durée de conservation par défaut des messages définie par Eventarc est de 24 heures avec un intervalle exponentiel entre les tentatives.
Vous pouvez mettre à jour la stratégie de nouvelle tentative via l'abonnement Pub/Sub associé au déclencheur Eventarc :
- Ouvrez la page de détails du déclencheur.
- Cliquez sur le thème.
- Cliquez sur l'onglet Abonnements.
Tout abonnement créé automatiquement par Eventarc aura le format suivant : projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Pour en savoir plus sur les limites d'abonnement, consultez la page Limites de ressources dans Pub/Sub.
Si Pub/Sub tente d'envoyer un message, mais que la destination ne peut pas en accuser réception, Pub/Sub renvoie à nouveau le message avec un intervalle exponentiel minimal entre les tentatives de 10 secondes. Si la destination continue de ne pas accuser réception du message, du temps est ajouté à chaque nouvelle tentative (jusqu'à 600 secondes) et le message est renvoyé à la destination.
Notez que Workflows accuse réception des événements dès le début de l'exécution du workflow.
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 la page Gérer les échecs de message.
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 de la destination du workflow, quelle que soit leur source, ne seront pas relancés si le workflow ne s'exécute pas. 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.
Rendre les 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.