GitHub sotto pressione: il retry storm nascosto nel tuo repo Cursor

GitHub non sta cedendo per una riga di codice, ma per il carico che si propaga

GitHub oggi gestisce 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. Il 17 agosto una sua interruzione è durata quasi otto ore: secondo il postmortem, un componente critico non è riuscito a scalare con il traffico e la pressione di capacità si è propagata fino a causare errori di autenticazione e disservizi su più funzioni.

La notizia arriva da “GitHub now sees 2.9 billion commits a month — and it can’t keep up”, pubblicato il 20 agosto 2026.

La lezione per chi fa startup non è soltanto “scegli un provider più affidabile”. È più concreta: quando il tuo prodotto dipende da webhook, API e job asincroni, un picco non gestito può trasformarsi in una coda infinita di retry. E il tuo codice può amplificare il problema anche se ogni singola richiesta, presa da sola, sembra corretta.

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina di aver usato Cursor per costruire una dashboard SaaS che sincronizza repository, issue e pull request. Ogni evento GitHub attiva un webhook nel tuo backend:

• arriva una notifica;
• il server aggiorna il database;
• un job ricalcola metriche o stato della build;
• l’interfaccia mostra il risultato al team.

Durante i test funziona. Poi GitHub rallenta, restituisce un errore temporaneo o consegna lo stesso evento più volte. Il tuo endpoint risponde con un codice non previsto, il provider ritenta, il tuo worker ritenta a sua volta e il sistema accoda nuove elaborazioni mentre sta ancora smaltendo le precedenti.

Il buco tecnico è un retry storm: una cascata di tentativi automatici che moltiplica il traffico proprio quando una dipendenza è già sotto pressione.

In un repo generato o modificato velocemente con Cursor, puoi trovare pattern come questi:

• retry immediati senza backoff;
• nessun limite massimo ai tentativi;
• eventi webhook processati più volte perché manca un idempotency key;
• timeout diversi tra API, worker e database;
• code senza capienza o senza dead-letter queue;
• risposte 5xx usate anche per errori permanenti;
• job duplicati quando il provider riconsegna lo stesso evento.

Non è un problema di aver usato Cursor. Cursor ti permette di implementare in fretta. Il rischio nasce quando la velocità di scrittura supera la verifica del comportamento sotto carico e in presenza di errori parziali.

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

Un audit del repository serve a ricostruire il percorso reale di una richiesta, dal webhook fino al database e alla risposta finale. Non guarda soltanto se il codice compila: cerca di capire cosa succede quando una dipendenza è lenta, risponde male o consegna due volte lo stesso messaggio.

Nel caso di un retry storm, il verdetto deve rispondere a domande precise:

1. Quali endpoint ricevono eventi esterni?
2. Il sistema riconosce gli eventi già elaborati?
3. Dove viene registrato lo stato del tentativo?
4. Esiste un backoff con jitter oppure i retry partono subito?
5. C’è un numero massimo di tentativi per evento?
6. Cosa succede agli errori permanenti, come un payload non valido?
7. I timeout sono coerenti tra client, API, worker e database?
8. Un fallimento del database può causare la riconsegna dello stesso job?
9. Esistono limiti di concorrenza per evitare che i worker saturino il sistema?
10. Gli effetti esterni sono idempotenti, o una ripetizione può creare doppie fatture, notifiche o modifiche?

Queste domande attraversano più file e più livelli dello stack. Il controller del webhook può sembrare corretto, mentre il problema sta nel worker. Il worker può avere un backoff, ma una libreria HTTP può aggiungere un secondo livello di retry. Il database può rispondere lentamente e indurre il provider a considerare fallita una richiesta che in realtà è stata già applicata.

È qui che serve un audit VibeInspect: ottenere un verdetto tecnico sul comportamento del repo e sulle evidenze che lo sostengono. Non una sensazione, non un “dovrebbe reggere”, non un test felice eseguito una volta.

Per un problema di performance e affidabilità, il piano coerente è il Diagnostic: restituisce file, righe ed evidenze sul difetto individuato. Lo Snapshot da €49 è utile per un primo score, ma non localizza il percorso del retry storm. L’audit consegna un PDF con il verdetto; non modifica il codice e non è un pentest.

Cosa un linter non vede

Un linter può rilevare una promessa non gestita, un import inutilizzato o una regola di stile violata. Non sa se un evento GitHub può essere ricevuto due volte e produrre due aggiornamenti identici.

Non sa nemmeno distinguere automaticamente tra un errore transitorio e uno permanente. Un timeout di rete può essere ritentato. Un payload non valido non dovrebbe essere riprovato all’infinito. Un’autorizzazione fallita non diventa corretta al quarto tentativo.

Il linter vede una chiamata come:

await processWebhook(event)

L’audit deve chiedersi cosa accade se processWebhook viene eseguita tre volte in parallelo, se il processo termina dopo aver scritto nel database ma prima di rispondere, oppure se il provider considera fallita una richiesta che il tuo server ha già completato.

Lo stesso vale per i job in coda. Un test può verificare che una fattura venga creata. Non dimostra necessariamente che la stessa fattura non venga creata due volte quando il job viene ripetuto dopo un timeout.

La differenza è tra correttezza locale e comportamento del sistema:

• correttezza locale: la funzione restituisce il risultato atteso;
• correttezza del flusso: il risultato resta corretto con retry, duplicati, timeout e concorrenza;
• affidabilità operativa: il sistema degrada senza trasformare un errore temporaneo in un incidente più grande.

Un audit cerca questi confini. Il nemico non è il codice AI-generated: è l’assenza di una risposta chiara alla domanda “cosa succede quando tutto rallenta insieme?”.

Cosa fare questa settimana

Prima del prossimo lancio o della prossima integrazione con GitHub, fai queste verifiche:

1. Mappa i webhook e le dipendenze esterne. Elenca endpoint, API, code, worker e database coinvolti.
2. Rendi idempotente ogni evento. Salva un identificatore unico e impedisci che lo stesso evento produca due effetti.
3. Imposta retry ragionati. Usa backoff, jitter, un limite massimo e una distinzione tra errori temporanei e permanenti.
4. Controlla i timeout end-to-end. Un timeout del client non deve contraddire quello del worker o del provider.
5. Limita la concorrenza. Un worker che scala senza budget può trasformare una coda in saturazione.
6. Prepara una dead-letter queue. Gli eventi che falliscono più volte devono uscire dal percorso automatico e diventare osservabili.
7. Prova il doppio invio. In staging consegna due volte lo stesso webhook e verifica database, notifiche e stato finale.
8. Chiedi un verdetto prima del go-live. Se non sai dire dove sono backoff, idempotenza e limiti, non hai ancora misurato il rischio.

Se hai spedito con Cursor e il tuo prodotto dipende da webhook, sincronizzazioni o job asincroni, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente viene cancellato a fine analisi.

Scegli il Diagnostic se vuoi sapere quali file e righe sostengono il problema di retry storm. Il punto non è dimostrare che Cursor ha scritto codice imperfetto: è sapere se il tuo repo amplifica il prossimo picco invece di assorbirlo.