Pourquoi mes webhooks arrivent en double et comment y remédier ?

[Logan.S]

Je suis en train de bosser sur un petit projet perso, et je me retrouve un peu coincé avec la partie qui gère les webhooks. J'ai tout configuré côté serveur, les événements se déclenchent bien, mais je reçois parfois le même payload plusieurs fois de suite, comme si le service externe me renvoyait la notification. C'est un peu énervant pour mettre à jour l'état dans ma base sans créer de doublons. Est-ce que c'est un truc classique avec les webhooks, cette histoire de livraison en double ? Certains d'entre vous ont-ils déjà eu ce souci et trouvé une façon simple de le gérer sans surcharger la logique ? J'ai l'impression de devoir ajouter pas mal de code juste pour de la déduplication.

[Zoey9]

Oui, c'est un truc classique avec les webhooks: on peut les recevoir en double ou en cascade, surtout si le service effectue des retries après un échec réseau. Le mot clé ici c'est déduplication et idempotence: traque l'event_id fourni par le payload et ne met à jour ta base que si cet event_id n'a pas encore été vu. Conserve un petit store des events traités (ou des hashes des payloads) et ignore les duplicatas. Ce n'est pas élégant comme solution, mais ça marche sans écrire un gros bus de messages.

[Victoria62]

J'ai l'impression que c'est plus la règle que l'exception: le client external envoie plusieurs fois par mesure de sécurité; si tu n'as pas de flag d'acknowledge, tu vas te retrouver avec des doublons. Ta logique doit être idempotente et viser la déduplication même si la signature est identique plusieurs fois. Vérifie aussi les headers et les codes de réponse: 200/204 pour signifier que c'est ok et éviter des retries.

[EvelynQW]

Franchement, voir le même payload repasser c'est agaçant, on a l'impression de se battre contre un bug invisible. La déduplication paraît lourde, mais c'est souvent le seul moyen sans réécrire tout le flux. Et oui, ça passe par stocker un identifiant unique et ignorer les duplicatas sans tripler les lignes de code.

[Jonathan.G]

Le vrai souci pourrait être la manière dont on pense le flux: le webhook devient une source d'événements sans garantie d'unicité. Le problème n'est peut-être pas le doublon lui-même mais l'absence d'idempotence dès l'entrée. Si on reformule: plutôt que de nettoyer les doublons après coup, on pourrait imposer une approche d'idempotence et d'event sourcing pour garder une trace transparente des changements.

[Jerry60]

Astuce rapide: calculer un hash du payload et stocker dans une table des processed; lors du webhook, vérifier si le hash existe; si oui, ignorer; sinon traiter et enregistrer le hash; répondre 204; penser à ajouter un header Request-Id pour faciliter les retries.

[BrianHG]

Et puis côté UX, les développeurs veulent que ce soit fiable sans trop de code boilerplate. Déduplication, oui, mais on peut aussi interroger le service côté expéditeur: certains envoient des tokens d'idempotence ou des en-têtes comme X-Webhook-Id; si ce n'est pas le cas, tu passes par l'historique des événements et par l'état final, sans tout mélanger. Bref, c'est faisable sans devenir un showroom de code.