Gestire eventi webhook ricevuti fuori ordine

L’ordine di arrivo dei webhook non garantisce l’ordine degli stati. I ritardi dei tentativi e il nuovo invio manuale possono far arrivare un payload precedente dopo un evento più recente; l’ora di creazione della riga di invio registra il tentativo, non la modifica originale.

Passaggi

1. Verifica la firma, elimina i duplicati tramite id dell’evento al livello principale e interpreta type, created, workspace_id e data. Gli ID evento sono valori opachi e non devono essere ordinati.
2. Salva created al livello principale come ora di occorrenza Unix in secondi, non come sequenza di ordinamento totale. Eventi distinti possono condividere lo stesso secondo e un nuovo invio mantiene il vecchio payload pur ricevendo una nuova riga di invio.
3. Per file.uploaded, associa lo stato a data.file_id e confronta l’intero data.version. Applica una versione superiore, tratta lo stesso ID evento come duplicato e ignora una versione inferiore arrivata dopo una più recente.
4. Per share.accessed, usa data.accessed_at per l’occorrenza dell’accesso e conserva ogni ID evento distinto. Due visualizzazioni di un link sono eventi separati anche se gli orari sono vicini.
5. Per file.deleted, nota che i payload attuali forniscono file_id, name e permanent, ma nessuna versione della risorsa. Riconcilia lo stato attuale di dosya tramite una lettura API autorizzata separata prima di attivare un’eliminazione irreversibile a valle.
6. Prova ritardando un evento di caricamento precedente, elaborando prima una versione superiore del file e poi rilasciando la vecchia richiesta. Verifica che la versione salvata non torni indietro e che entrambi i tentativi ricevano conferme deliberate.

Il mittente non garantisce un ordine tra eventi o endpoint. Mantieni uno stato monotono per risorsa dove esiste un campo affidabile e riconcilia lo stato attuale dove manca.

Risultato previsto

Il ricevitore converge sulla versione più recente nota del file, conserva gli accessi distinti alle condivisioni e non deduce l’ordine di eliminazione da ID casuali o orari di invio. I tentativi tardivi non possono riportare indietro lo stato a valle.

Due eventi hanno lo stesso valore created. Usa il campo specifico della risorsa o riconcilia lo stato attuale; il timestamp dell’involucro ha precisione di un secondo.

Un’eliminazione non può essere riconciliata. Isola l’evento per la revisione di un operatore e rispondi secondo la regola di nuovi tentativi del ricevitore, senza indovinare una transizione irreversibile.

Guide correlate

• Verificare le firme webhook
• Controllare gli invii