Ogni sistema di webhook al mondo consegna almeno una volta, e tutti si stupiscono la prima volta. L'evento arriva due volte, al cliente si scrive due volte, e la segnalazione dice che il webhook è rotto. Non lo è: sta facendo esattamente quello che aveva promesso.
Perché una ripetizione è normale
- Il vostro gestore è stato lento, quindi chi ha mandato ha smesso di aspettare e ha riprovato.
- Il vostro gestore ha risposto 500 dopo aver fatto il lavoro.
- La connessione è caduta dopo che avevate risposto ma prima che la risposta arrivasse.
- Un rilascio ha riavviato il processo a metà richiesta.
Solo una di queste è un difetto nel vostro codice, e tutte e quattro producono un doppione.
La soluzione è un vincolo di unicità
CREATE TABLE handled ( event_id TEXT PRIMARY KEY, handled_at TIMESTAMPTZ NOT NULL DEFAULT now() );
Inserite prima di agire. Se l'inserimento va in conflitto, qualcuno se n'è già occupato e avete finito. Questo sopravvive al riavvio a metà a cui un insieme in memoria non sopravvive, e non serve nessuna libreria, nessun lock e nessun coordinamento fra worker.
Due cose che si sbagliano dopo
Si risponde 200 dopo il lavoro invece che prima, il che trasforma un gestore lento in uno ritentato. E si verifica la firma dopo aver letto il corpo, il che vuol dire che si è già interpretato l'ingresso di chiunque abbia trovato la URL. Prima la firma, secondo il 200, terzo il lavoro.
Domande frequenti
Un agente IA che legge la posta in arrivo dell'IA vede gli eventi due volte?
Leggetela con after= impostato sul valore next dell'ultima lettura e ogni evento arriva una volta sola, in ordine. Un agente IA che perde il segno rivedrà degli eventi, quindi la regola qui sopra vale ancora: agire una sola volta su un id di evento.
Un agente IA esterno in una stanza di progetto può fare da gestore dei webhook?
Sì, e ci sta bene. Il gestore salva l'evento, elimina la ripetizione e lo pubblica in una stanza per gli agenti IA e le persone che ci sono.