Ritentare gli invii webhook in sicurezza

I tentativi ripetuti sono normali, quindi il ricevitore deve poter eseguire un evento più volte in sicurezza. L’identificativo stabile dell’evento dosya è l’ID evento; un ID invio identifica un record di tentativo e può cambiare nel reinvio manuale.

Passaggi

1. Verifica X-Dosya-Signature rispetto al corpo grezzo e richiedi la corrispondenza tra X-Dosya-Event-Id e id nel corpo prima di avviare la transazione.
2. Inserisci l’ID evento in una tabella di idempotenza con vincolo di unicità nella stessa transazione che applica la modifica a valle. Conserva stato di elaborazione e riferimento sicuro al risultato per il recupero.
3. In caso di conflitto della chiave univoca, leggi il risultato confermato e restituisci 2xx senza ripetere la modifica. Non usare X-Dosya-Delivery-Id come unica chiave perché Invia di nuovo ne assegna una nuova.
4. Conferma il lavoro persistente prima di rispondere. Un arresto del ricevitore prima del commit consente un nuovo tentativo sicuro; confermare separatamente effetto e relativo marcatore crea un intervallo in cui il tentativo successivo può duplicare lo stato.
5. Prova una volta il percorso di errore. dosya invia un primo tentativo e, se l’errore persiste, ne pianifica altri cinque dopo 30 secondi, 2 minuti, 10 minuti, 1 ora e 6 ore; il controllo può avvenire dopo ciascuna scadenza.
6. Lascia riuscire il nuovo tentativo ed esamina Invii. Conferma un solo risultato, un ID evento condiviso, il numero di tentativi e Operazione completata senza ulteriori tentativi pianificati.

Qualsiasi 2xx termina i tentativi. Una risposta non 2xx, un errore di rete, un reindirizzamento non consentito o un timeout di dieci secondi incrementa gli errori consecutivi della destinazione webhook; 15 errori disattivano automaticamente la destinazione.

Risultato previsto

Le richieste ripetute per lo stesso evento creano il singolo risultato previsto a valle oppure restituiscono il risultato confermato. I tentativi restano osservabili senza diventare ulteriori operazioni.

L’effetto è avvenuto due volte. Sposta registrazione dell’idempotenza e modifica in un unico confine atomico, poi correggi i duplicati esistenti prima di reinviare l’evento.

Un evento problematico viene ritentato ripetutamente. Metti in quarantena persistente il contenuto verificato e scegli una regola di conferma deliberata; restituire un errore consuma i sei tentativi e contribuisce alla disattivazione automatica.

Guide correlate

• Guida rapida API REST
• Esaminare gli invii webhook