GitHub non regge il picco: il retry storm nascosto nel tuo repo Bolt

Il problema non è solo il picco: è ciò che il software fa dopo

GitHub ha pubblicato i numeri dietro il recente incidente: 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. Il 17 agosto, un componente dell’infrastruttura non è riuscito a scalare con il traffico; la pressione si è propagata fino a causare errori di autenticazione e interruzioni su più servizi. L’incidente è durato quasi otto ore.

La notizia completa è qui: GitHub now sees 2.9 billion commits a month — and it can’t keep up.

Per chi ha spedito un prodotto costruito con un coding agent, il punto non è chiedersi se il proprio servizio riceverà mai il traffico di GitHub. Non succederà. Il punto è più concreto: cosa fa il tuo repo quando una dipendenza rallenta, una richiesta scade o un servizio restituisce un errore temporaneo?

Molti progetti vibe-coded funzionano finché tutto risponde al primo colpo. Il problema emerge al secondo tentativo.

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina un’app costruita con Bolt che riceve un evento da un webhook: pagamento completato, documento caricato, invito accettato o sincronizzazione avviata.

La richiesta entra nel backend. Il backend chiama un servizio esterno. Il servizio risponde lentamente o va in timeout. Il codice interpreta il timeout come un errore temporaneo e riprova. Anche il secondo tentativo fallisce, quindi parte un terzo. Nel frattempo il client, che non ha ricevuto risposta, invia di nuovo la richiesta. Un job in coda prova a fare la stessa operazione. Un altro worker riparte dopo il suo timeout.

Non hai più una richiesta. Hai una moltiplicazione di richieste.

Questo è un retry storm: un errore locale che diventa pressione aggiuntiva sul sistema proprio mentre il sistema è già in difficoltà. Se il flusso non è idempotente, puoi anche creare duplicati: due addebiti, due email, due record, due aggiornamenti dello stesso ordine.

Bolt può aiutarti a costruire rapidamente l’interfaccia, le API e il collegamento tra servizi. Non può però sapere, da solo, quale sia il verdetto operativo del tuo repo:

• quante volte può essere ritentata una stessa operazione;
• se il retry ha un limite e un backoff reale;
• se un timeout interrompe davvero il lavoro precedente;
• se un webhook duplicato viene riconosciuto;
• se un fallback evita di peggiorare il sovraccarico;
• se un errore viene registrato con abbastanza contesto per essere ricostruito.

La UI può essere perfetta. Il flusso può fallire nel modo più costoso possibile.

Perché ora ti serve un audit: il verdetto che manca

Il tuo linter può dirti che una variabile non è usata, che una promessa non è gestita o che una regola di stile non viene rispettata. Non ti dirà se tre componenti diversi possono ritentare lo stesso pagamento nello stesso momento.

Un audit serve a trasformare una sensazione — “in produzione potrebbe esplodere” — in un verdetto sul comportamento concreto del repository.

Per questo caso, il verdetto deve rispondere a una domanda semplice: quando un servizio esterno è lento o indisponibile, il tuo sistema degrada con controllo oppure genera altro traffico e altri effetti collaterali?

Non basta vedere una funzione chiamata retryRequest. Serve capire il percorso completo: chi la invoca, quale errore la attiva, quale stato viene salvato, cosa succede dopo il timeout e se la richiesta può essere ripetuta da un altro punto della stessa architettura.

Un audit VibeInspect analizza il repository e restituisce un PDF con score, verdetto e — nel piano Diagnostic — evidenze riferite a file e righe. Non sistema il codice e non sostituisce un test di carico. Ti dice però se il rischio è reale, dove si concentra e quanto è vicino al percorso che porta valore o denaro nel tuo prodotto.

Il nemico non è avere usato Bolt. Il nemico è spedire senza sapere quale comportamento aspettarti quando qualcosa va storto.

Perché ora ti serve un audit: le evidenze che devi cercare

Nel repo, cerca un solo problema alla volta: la gestione dei retry e dei duplicati nelle operazioni esterne.

Le evidenze utili non sono soltanto “c’è un retry”. Sono combinazioni come queste:

1. Retry senza backoff o con un numero non limitato. Se ogni errore produce una nuova chiamata quasi immediata, il sistema può aumentare il carico durante il picco.

2. Timeout applicati a livelli diversi. Il frontend può scadere dopo cinque secondi, l’API dopo trenta e il worker dopo due minuti. Lo stesso lavoro può quindi restare attivo mentre un altro livello lo considera fallito e lo riparte.

3. Assenza di idempotency key. Se lo stesso evento arriva due volte, il codice potrebbe eseguire due volte un’azione che dovrebbe avvenire una sola volta.

4. Webhook accettato prima della deduplicazione. Salvare l’evento dopo aver eseguito l’azione significa che due richieste ravvicinate possono superare entrambe il controllo.

5. Coda senza limite o senza circuit breaker. Quando il servizio esterno non risponde, accumuli lavoro proprio mentre la capacità utile diminuisce.

6. Fallback che nasconde l’errore. Restituire sempre 200 OK o una risposta apparentemente valida può impedire agli strumenti di monitoraggio di capire che il sistema è degradato.

Il punto dell’audit è collegare questi indizi. Una singola riga raramente dimostra il rischio. Lo dimostra il percorso: evento, handler, servizio esterno, retry, persistenza, risposta e nuovo tentativo.

Cosa un linter non vede

Un linter lavora soprattutto su regole locali. L’errore che stiamo cercando è invece distribuito nel comportamento.

Il linter non vede che:

• due endpoint diversi aggiornano lo stesso record senza una protezione comune;
• un job asincrono può partire mentre la richiesta HTTP originale non è ancora terminata;
• un retry del provider e un retry applicativo si sommano;
• un errore transitorio viene trasformato in una risposta positiva;
• una richiesta ripetuta produce un nuovo effetto invece di restituire il risultato già registrato;
• l’assenza di una metrica rende invisibile la crescita della coda.

Nemmeno una suite di test minima garantisce che il problema sia escluso. Puoi avere test verdi per il caso nominale e non aver mai simulato: due richieste simultanee, una risposta lenta, un timeout dopo l’avvenuta elaborazione o un provider che restituisce cinque errori consecutivi.

Il linter controlla la forma. L’audit cerca il comportamento e il verdetto.

Cosa fare questa settimana

Prima di cambiare codice, fai una mappa di un solo flusso critico: pagamento, invio email, provisioning o sincronizzazione dati.

Poi verifica:

• qual è l’identificatore univoco dell’operazione;
• dove viene registrato lo stato;
• quanti retry esistono e chi li applica;
• cosa succede se la risposta arriva dopo il timeout;
• se due worker possono elaborare lo stesso evento;
• quale log permette di ricostruire l’intero percorso.

Se non sai rispondere con precisione, non ti serve un altro refactor generato dall’AI. Ti serve un verdetto sul repo.

Carica lo ZIP su VibeInspect.ai. Per questo caso sceglierei il piano Diagnostic: il problema è tecnico e hai bisogno di evidenze su file, righe e flussi, non soltanto di uno score.

L’obiettivo non è dimostrare che Bolt ha scritto codice “brutto”. È sapere se il tuo prodotto, sotto errore, assorbe il colpo oppure lo amplifica.