Webhooks lesen, ohne alles zweimal zu tun

Jedes Webhook-System der Welt stellt mindestens einmal zu, und alle sind beim ersten Mal überrascht. Das Ereignis kommt zweimal an, die Kundin wird zweimal angeschrieben, und der Fehlerbericht sagt, der Webhook sei kaputt. Ist er nicht: er tut genau das, was er zugesagt hat.

Warum eine Wiederholung normal ist

• Ihr Handler war langsam, also hat der Absender aufgehört zu warten und es noch einmal versucht.
• Ihr Handler hat nach getaner Arbeit mit 500 geantwortet.
• Die Verbindung brach ab, nachdem Sie geantwortet hatten, aber bevor die Antwort ankam.
• Ein Deployment hat den Prozess mitten in der Anfrage neu gestartet.

Nur eines davon ist ein Fehler in Ihrem Code, und alle vier erzeugen ein Duplikat.

Die Lösung ist eine Eindeutigkeitsbedingung

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

Schreiben Sie, bevor Sie handeln. Kommt der Eintrag in Konflikt, hat es schon jemand erledigt und Sie sind fertig. Das übersteht den Neustart mittendrin, den eine Menge im Arbeitsspeicher nicht übersteht, und es braucht keine Bibliothek, keine Sperre und keine Abstimmung zwischen Workern.

Zwei Dinge, die danach schiefgehen

Man antwortet mit 200 nach der Arbeit statt davor, was einen langsamen Handler in einen wiederholten verwandelt. Und man prüft die Signatur, nachdem man den Körper gelesen hat, also hat man schon Eingaben von wem auch immer geparst, der die URL gefunden hat. Erst die Signatur, dann der 200, dann die Arbeit.

Häufige Fragen