GitHub va in crisi sotto il traffico: il tuo webhook può fare lo stesso

Un picco non dovrebbe trasformarsi in un blackout

GitHub ha pubblicato il postmortem di un outage durato quasi otto ore. Il problema non è partito da una modifica al codice, ma da un picco di traffico che ha mandato in saturazione un componente dell’infrastruttura. La pressione si è propagata fino a causare errori di autenticazione e disservizi su più funzionalità.

Il dettaglio utile per un founder è un altro: GitHub sta intervenendo su retry, timeout, osservabilità e dipendenze condivise per ridurre il rischio di retry storm e carico a cascata. La notizia è GitHub now sees 2.9 billion commits a month — and it can’t keep up.

Il tuo prodotto non gestisce miliardi di commit. Ma lo stesso meccanismo può comparire in un repository molto più piccolo: basta un webhook che fallisce, ritenta senza limite e moltiplica le richieste proprio quando un servizio esterno è già sotto pressione.

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina di aver usato Bolt per costruire un’app che sincronizza pagamenti, ordini o aggiornamenti di un CRM tramite webhook. Il flusso sembra lineare:

1. arriva un evento dal provider;
2. il tuo endpoint lo riceve;
3. l’app aggiorna il database;
4. la risposta 200 conferma l’elaborazione.

Quando tutto funziona, non c’è nulla da notare.

Poi il database rallenta per qualche secondo. Oppure il provider risponde con un timeout. Il tuo endpoint non completa il lavoro e restituisce un errore. Il provider ritenta. Il secondo tentativo arriva mentre il primo è ancora in coda. Il codice prova a elaborare entrambi, fallisce di nuovo e genera altri retry.

Il problema tecnico è uno solo: un webhook non idempotente con retry non controllati.

In pratica, lo stesso evento può creare due ordini, duplicare un rimborso, inviare più email o aggiornare più volte lo stesso record. Se il retry è gestito sia dal provider sia dalla tua applicazione, il numero di richieste può crescere rapidamente. Un piccolo rallentamento diventa congestione; la congestione produce nuovi timeout; i timeout producono altri retry.

Bolt può averti generato un handler perfettamente leggibile. Può anche aver aggiunto un blocco try/catch, un timeout e un messaggio di log. Ma la resilienza non è una singola istruzione: dipende dal rapporto tra provider, endpoint, coda, database, chiave dell’evento e risposta restituita.

Perché ora ti serve un audit

Qui non ti serve un’altra demo. Ti serve sapere se il tuo repository contiene un percorso capace di amplificare un errore temporaneo.

La domanda è: se lo stesso webhook arriva due o tre volte, il sistema produce ancora una sola conseguenza corretta?

Per rispondere bisogna seguire l’intero flusso:

• dove viene ricevuto l’evento;
• come viene verificata la firma del provider;
• quale identificatore univoco viene estratto dall’evento;
• se quell’identificatore viene salvato prima di eseguire l’azione;
• se un secondo tentativo viene ignorato in modo sicuro;
• quali errori generano una nuova consegna;
• se l’applicazione ritenta a sua volta la stessa operazione;
• come vengono gestiti timeout, code e transazioni parziali.

Un audit VibeInspect analizza il repository in ZIP e produce un PDF con score e verdetto. Nel piano Diagnostic, il report include file, righe ed evidenze per collegare il webhook al database, alla logica di retry e all’azione finale.

Il verdetto utile non è “il webhook sembra funzionare”. È: PASS, perché l’evento è idempotente e il retry è bounded; oppure FAIL, perché lo stesso evento può ripetere l’azione o generare una spirale di richieste.

Il punto è importante anche se non hai ancora visto un incidente. L’assenza di errori nei log durante i test normali non dimostra che il flusso regga quando un servizio dipendente rallenta. Devi verificare il comportamento nel momento peggiore, non solo nel caso felice.

Il report deve dimostrare cosa succede al secondo tentativo

Un falso positivo è facile. Trovare retry, setTimeout o una coda nel repository non dimostra da solo che esista un retry storm.

Potresti avere un meccanismo corretto: massimo tre tentativi, backoff progressivo, chiave idempotente e una coda che separa la ricezione dell’evento dall’elaborazione. Oppure potresti avere una combinazione più fragile: risposta lenta, inserimento nel database prima della deduplicazione e nuovo tentativo automatico su ogni eccezione.

L’evidenza deve quindi collegare almeno quattro elementi:

1. il punto in cui l’evento entra nel sistema;
2. il modo in cui viene identificato e registrato;
3. l’operazione che modifica lo stato o produce un effetto esterno;
4. la condizione che decide se riprovare.

Se manca la chiave idempotente, il secondo evento può essere indistinguibile dal primo. Se la chiave esiste ma viene salvata dopo l’invio dell’email o la creazione dell’ordine, una race condition può comunque duplicare l’azione. Se l’handler risponde solo dopo aver completato tutto il lavoro, un timeout del provider può generare una nuova consegna mentre il primo processo sta ancora terminando.

Un audit tecnico serve a mettere insieme questi dettagli e a trasformarli in una decisione. Non deve limitarsi a elencare “possibili problemi di resilienza”. Deve dirti se il percorso reale può amplificare il traffico o duplicare una conseguenza.

Cosa un linter non vede

Un linter controlla regole locali: sintassi, tipi, import, formattazione e alcuni pattern conosciuti. Non sa necessariamente che un provider esterno ritenta quando non riceve una risposta in tempo.

Non ricostruisce sempre la differenza tra un errore transitorio e un errore permanente. Non conosce il contratto operativo del webhook. Non può stabilire da solo se un evento viene registrato prima dell’effetto, se la transazione è atomica o se due richieste concorrenti possono passare entrambe il controllo di deduplicazione.

Anche i test possono tranquillizzarti troppo. Se invii un solo webhook e aspetti una risposta, puoi dimostrare che il caso normale funziona. Devi invece provare almeno questi scenari:

• lo stesso evento arriva due volte;
• arrivano due eventi quasi contemporaneamente;
• il database risponde lentamente;
• l’azione esterna va a buon fine ma la risposta HTTP fallisce;
• il provider ritenta mentre il primo tentativo è ancora attivo.

Il linter ti dice che il codice rispetta certe regole. L’audit ti dice se, nel contesto del tuo repository, un errore locale può diventare un problema di disponibilità o di dati duplicati.

Cosa fare questa settimana

1. Scegli il webhook più vicino a denaro, ordini, accessi o comunicazioni con i clienti.
2. Disegna il percorso dall’evento ricevuto fino all’effetto finale.
3. Verifica che ogni evento abbia una chiave univoca e che venga registrata prima dell’azione irreversibile.
4. Ripeti lo stesso evento due volte e controlla che il risultato resti uno solo.
5. Imposta un numero massimo di retry e un backoff esplicito; evita loop senza limite.
6. Separa la ricezione dalla lavorazione quando il compito può durare più del timeout del provider.
7. Controlla cosa succede se l’azione esterna riesce ma la risposta HTTP non arriva.
8. Se hai usato Bolt e non sai formulare un verdetto sul webhook, esegui un audit Diagnostic prima del prossimo rilascio.

Non devi smettere di usare Bolt. Devi smettere di considerare “ha ricevuto l’evento” come sinonimo di “il flusso è resiliente”. La velocità dell’AI ti porta rapidamente a una prima versione. Il controllo serve a capire se quella versione gestisce anche il secondo tentativo, il timeout e il picco che non avevi previsto.

Carica lo ZIP del repository e ottieni un verdetto con evidenze tecniche: avvia un audit Diagnostic.