La gestione dei nuovi tentativi del webhook è un problema di gestione dello stato. Un mittente può riconsegnare dopo un timeout anche quando il destinatario ha completato del lavoro. Se ogni tentativo crea un nuovo ticket o ripete una modifica, l’integrazione trasforma un normale guasto della rete in un incidente operativo.
Distinguere i tentativi di consegna dagli effetti aziendali
Definire una chiave di consegna utilizzando l'identità documentata del provider e l'ambito dell'abbonamento o del tenant. Definire separatamente l'effetto aziendale, ad esempio l'aggiornamento di un risultato di autenticazione esistente. Più eventi validi possono legittimamente riferirsi allo stesso risultato, mentre la consegna ripetuta di un evento non dovrebbe applicare il suo effetto due volte.
Guida al webhook di GitHub afferma che le riconsegne richieste mantengono X-GitHub-Delivery. Si consiglia inoltre di rispondere con un 2XX entro dieci secondi e di considerare l'elaborazione asincrona. Trattateli come comportamenti documentati specifici di GitHub. Non promettere che ogni provider ritenti o utilizzi automaticamente lo stesso timeout; confermare la sua politica di consegna effettiva e il percorso di recupero della mancata consegna.
Riconoscere al confine destro
Verificare innanzitutto l'evento, quindi registrare in modo duraturo il lavoro accettato prima di riconoscere il successo. Elabora lavori costosi da una coda. Se l'accettazione duratura fallisce, non inviare una risposta di successo semplicemente perché l'analisi ha avuto esito positivo. Al contrario, non tenere aperta una connessione fino al termine di una lunga indagine a valle quando il provider richiede una risposta rapida.
Utilizza stati come in coda, in elaborazione, nuovo tentativo in sospeso, completo e lettera non recapitata. Tieni traccia del conteggio dei tentativi e dell'ora del tentativo successivo. Un arresto anomalo del lavoratore può lasciare abbandonata una richiesta di elaborazione, quindi definire una regola di locazione o ripristino sicura. Proteggi l'unicità e le transizioni di stato con vincoli o transazioni del database anziché con un controllo di lettura e scrittura vulnerabile alle consegne simultanee.
Progettare effetti riproducibili
Per le chiamate esterne, utilizzare una chiave di idempotenza supportata o un'identità di destinazione stabile, ove disponibile. Quando un timeout lascia l'esito incerto, leggere o riconciliare l'obiettivo prima di ripetere un effetto collaterale. Se l'API downstream non è in grado di offrire idempotenza, documenta il rischio di duplicazione residua e aggiungi un percorso di revisione compensativo.
Supponiamo che una consegna verificata sia permanentemente in coda, ma la sua risposta di successo sia persa. Una riconsegna richiesta successivamente dovrebbe trovare lo stesso stato di consegna, non creare un secondo ticket semplicemente perché è arrivata un'altra richiesta HTTP. Separatamente, supponiamo che il lavoratore chiami un'API del ticket e vada in timeout dopo che l'API potrebbe aver creato il ticket. La sola deduplicazione della consegna della coda non può risolvere questa incertezza a valle: ispezionare la destinazione o utilizzare la chiave di idempotenza supportata prima di ripetere la creazione.
Si tratta di percorsi di errore ipotetici, non di una coda eseguita, di un test dell'orologio virtuale o di una garanzia esattamente una volta. Testare duplicati simultanei, interruzione del lavoratore, contratto di locazione di elaborazione abbandonato ed esaurimento limitato utilizzando l'effettivo contratto di archiviazione e downstream. Un elemento lettera non recapitata dovrebbe conservare prove sicure e richiedere una riproduzione controllata dopo che la sua causa è stata corretta, anziché reimpostare silenziosamente il conteggio dei tentativi.
Chiudi il cerchio sul lavoro esaurito
Utilizza tentativi limitati con backoff e segnali di limite di velocità applicabili. Migliori pratiche REST di GitHub spiegare il comportamento in grado di riconoscere il limite di velocità per tale API; applicare alla produzione il contratto di servizio effettivo a valle. Sposta gli articoli ripetutamente difettosi in una coda di messaggi non recapitabili controllata e avvisa l'operatore responsabile con prove sicure e il passaggio successivo.
Separare gli errori di trasporto ripetibili dagli errori permanenti di schema o autorizzazione. La riproduzione di una richiesta non autorizzata per un tempo indefinito non ne risolverà l'autorizzazione. Conservare sufficienti prove dell'identità e dei risultati per spiegare lo stato finale di ogni evento e fornire una procedura di riproduzione deliberata da parte dell'operatore dopo la correzione. Monitora il lavoro in coda più vecchio, riprova l'esaurimento e i risultati irrisolti, non solo il conteggio delle risposte HTTP riuscite. Qui non viene dimostrato alcun comportamento di tentativo del provider attivo o funzionalità EmailAuth .