GitHub non regge il carico: cosa controllare nel tuo repo creato con Cursor

GitHub ha aggiunto capacità, ma il problema era il modo in cui il sistema reagiva al picco

GitHub ha pubblicato i numeri dietro la sua recente crisi operativa: 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. Durante l’ultimo incidente, 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.

Il punto interessante non è solo che GitHub abbia raggiunto un nuovo picco. È che un singolo collo di bottiglia, combinato con retry e timeout non abbastanza coordinati, può trasformare un rallentamento locale in un problema sistemico. La piattaforma ha indicato proprio budget di retry e timeout più coerenti tra le misure da adottare per evitare retry storm e carico a cascata. La notizia completa è in “GitHub now sees 2.9 billion commits a month — and it can’t keep up”, pubblicata da The New Stack il 20 agosto 2026.

Cosa significa se il tuo codice l’ha scritto Cursor

Se hai usato Cursor per costruire un SaaS, una dashboard o un’app con API, potresti avere già lo stesso problema in miniatura: un endpoint lento fallisce, il client ritenta, il server ritenta verso il database o un servizio esterno, e ogni richiesta genera nuove richieste.

Nel prototipo funziona. Con pochi utenti sembra persino una buona scelta: “se qualcosa va storto, riproviamo”. In produzione, però, un retry senza limite, senza backoff e senza idempotenza può moltiplicare il traffico proprio quando un servizio è sotto pressione.

Il buco tecnico di oggi è questo: retry storm su chiamate applicative.

Un esempio tipico in un repo generato rapidamente con Cursor:

• il frontend ripete una richiesta dopo un timeout;
• l’API ripete la chiamata verso Stripe, un webhook o un servizio di ricerca;
• il worker riprende lo stesso job perché non trova una conferma definitiva;
• nessun componente sa distinguere tra una richiesta nuova e una già elaborata.

Il risultato non è necessariamente un crash immediato. Può essere un’app che diventa lenta, costosa e imprevedibile proprio durante un picco, quando servirebbe il comportamento opposto.

Perché ora ti serve un audit

Un linter può dirti che una variabile non viene usata o che una regola di formattazione non è rispettata. Non può dirti, da solo, se tre livelli diversi della tua applicazione stanno ritentando la stessa operazione in modo incompatibile.

Un audit serve a produrre un verdetto sul rischio reale del repository: non “il codice sembra ordinato”, ma “questo flusso può generare richieste duplicate e propagare il sovraccarico?”.

Nel caso dei retry storm, il controllo deve seguire il percorso completo:

1. Ingresso della richiesta: esistono timeout e limiti per utente, endpoint o job?
2. Chiamate interne: ogni client ha una propria politica di retry? Quante volte può riprovare?
3. Dipendenze esterne: il codice tratta allo stesso modo un errore transitorio, un errore definitivo e una risposta ambigua?
4. Persistenza: un retry può creare due ordini, due addebiti, due record o due notifiche?
5. Code e worker: il job viene marcato come in esecuzione? Esiste un limite ai tentativi? Cosa succede dopo il fallimento?
6. Osservabilità: puoi collegare i tentativi allo stesso request ID e capire quanto traffico aggiuntivo stanno generando?

Il valore non sta nel trovare una singola riga sbagliata. Sta nel ricostruire la catena e dirti dove il sistema può amplificare un errore.

Con VibeInspect carichi uno ZIP del repository e ricevi un PDF con score, evidenze e verdetto. Il codice viene cancellato a fine analisi. Lo Snapshot è utile se vuoi una prima fotografia del rischio; se il problema è tecnico e vuoi sapere quali file e righe sono coinvolti, il piano coerente è Diagnostic.

Il verdetto che ti manca prima del go-live

Quando hai vibe-codato, spesso hai già visto l’app funzionare. Hai cliccato i flussi principali, corretto gli errori mostrati dall’agente e magari aggiunto qualche test. Quello che manca è una risposta indipendente a una domanda più scomoda:

cosa succede quando la dipendenza rallenta, risponde tardi o risponde due volte?

Un audit non promette che il sistema sia perfetto e non sostituisce una revisione umana. Ti dà però una mappa concreta delle condizioni che il tuo percorso felice non copre: retry annidati, timeout incoerenti, operazioni non idempotenti, fallback che nascondono il problema e code che rilanciano indefinitamente lo stesso lavoro.

Cosa un linter non vede

Un linter lavora soprattutto sulla forma locale del codice. Il retry storm è invece un problema di comportamento distribuito.

Il linter può vedere che chiami una funzione di rete. Difficilmente valuterà che quella funzione viene chiamata da un hook frontend, da un middleware e da un worker, ognuno con un proprio meccanismo di ripetizione.

Può segnalare un’eccezione non gestita. Non sa necessariamente se il tuo catch rilancia l’operazione senza distinguere un 429 da un errore di validazione permanente.

Può verificare che i test passino. Non sa se i test coprono una connessione che cade dopo che il pagamento è stato accettato, un webhook consegnato due volte o due worker che prendono lo stesso job contemporaneamente.

Per questo il controllo deve guardare flussi, dipendenze e confini: non solo file isolati. Il problema non è che Cursor abbia scritto il codice. Il problema è spedire senza un verdetto su come il sistema reagisce fuori dal percorso ideale.

Cosa fare questa settimana

Dedica un’ora al flusso più costoso o più delicato del tuo prodotto e annota:

• ogni chiamata a un servizio esterno;
• chi può ritentare e quante volte;
• quali errori sono temporanei e quali no;
• quali operazioni devono essere idempotenti;
• dove viene registrato lo stato del job;
• quale limite ferma una cascata di retry;
• come colleghi i tentativi alla stessa richiesta.

Poi cerca nel repository parole come retry, timeout, catch, setTimeout, queue, attempt, backoff e idempotency. Non fermarti al risultato testuale: ricostruisci il percorso tra browser, API, database e provider esterni.

Se non riesci a dire con sicurezza quanti tentativi può generare una singola azione dell’utente, non hai ancora un verdetto sul go-live.

Carica il repo su VibeInspect.ai e parti dal piano Snapshot se non sai ancora quanto è esteso il problema. Se vuoi evidenze file/riga sul meccanismo di retry, scegli Diagnostic. L’obiettivo non è umiliare chi ha usato Cursor: è smettere di confondere “ha funzionato una volta” con “regge quando il sistema è sotto pressione”.