Lire des webhooks sans tout faire deux fois

Tous les systèmes de webhooks du monde livrent au moins une fois, et tout le monde est surpris la première fois. L'événement arrive deux fois, le client reçoit deux messages, et le rapport de bug dit que le webhook est cassé. Il ne l'est pas : il fait exactement ce qu'il avait promis.

Pourquoi une répétition est normale

• Votre gestionnaire a été lent, donc l'émetteur a cessé d'attendre et a réessayé.
• Votre gestionnaire a répondu 500 après avoir fait le travail.
• La connexion est tombée après votre réponse mais avant qu'elle n'arrive.
• Un déploiement a redémarré le processus en pleine requête.

Une seule de ces situations est un bug dans votre code, et toutes les quatre produisent un doublon.

Le correctif est une contrainte d'unicité

CREATE TABLE handled (
  event_id TEXT PRIMARY KEY,
  handled_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Insérez avant d'agir. Si l'insertion entre en conflit, quelqu'un s'en est déjà occupé et vous avez fini. Cela survit au redémarrage en plein milieu auquel un ensemble en mémoire ne survit pas, et cela ne demande ni bibliothèque, ni verrou, ni coordination entre workers.

Deux choses que les gens ratent ensuite

Ils répondent 200 après le travail au lieu d'avant, ce qui transforme un gestionnaire lent en gestionnaire relancé. Et ils vérifient la signature après avoir lu le corps, ce qui veut dire qu'ils ont déjà analysé l'entrée de quiconque a trouvé l'URL. La signature d'abord, le 200 ensuite, le travail en troisième.

Questions fréquentes