GitHub sotto pressione: il webhook fragile nel tuo repo Cursor

Quando anche GitHub non regge più il ritmo dei commit

GitHub ha raggiunto una scala impressionante: 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. Eppure il 17 agosto una parte dell’infrastruttura è rimasta fuori uso per quasi otto ore, dopo che un componente non è riuscito a scalare con il traffico. La pressione si è propagata fino all’autenticazione e ad altri servizi.

La notizia è raccontata da The New Stack nell’analisi sull’outage di GitHub. Il punto interessante, per chi spedisce software con agenti AI, non è solo che GitHub può andare giù. È che il volume generato da Cursor, Copilot e dagli altri coding agent sta cambiando il tipo di guasti che il tuo repo deve saper assorbire.

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina il flusso tipico di un prodotto costruito o evoluto con Cursor:

1. un agente apre una branch;
2. modifica più file;
3. esegue test e build;
4. apre una pull request;
5. un webhook avvia CI, preview, deploy, notifiche e sincronizzazioni;
6. un secondo evento aggiorna lo stato del primo.

Finché il ritmo è umano, un design fragile può sembrare sufficiente. Quando branch e pull request vengono create in parallelo, il problema cambia: un webhook lento può andare in timeout, il provider può ritentare la consegna, il tuo handler può processare due volte lo stesso evento e ogni retry può generare altri eventi.

Il buco concreto è una gestione non idempotente dei webhook. Non serve un attacco sofisticato. Basta un timeout transitorio, una risposta 500 o una coda senza limite. Il risultato può essere un deploy duplicato, una preview sovrascritta, una notifica ripetuta decine di volte o una pipeline che consuma risorse fino a rallentare il prodotto.

Il codice può funzionare perfettamente nel caso felice e fallire proprio quando il sistema è sotto pressione. È il tipo di difetto che tende a restare nascosto in un repository prodotto velocemente dall’AI: ogni componente sembra ragionevole, ma nessuno ha verificato il comportamento dell’intero flusso quando gli eventi arrivano fuori ordine, duplicati o in ritardo.

Perché ora ti serve un audit

Un audit non parte dal presupposto che Cursor abbia scritto “brutto codice”. Parte da una domanda più utile: il tuo repo ha un verdetto verificabile prima che il traffico reale lo costringa a rivelare i suoi limiti?

Nel caso dei webhook, un audit tecnico cerca evidenze concrete lungo il percorso:

• esiste un identificatore univoco dell’evento?
• il servizio salva gli eventi già elaborati?
• due consegne identiche producono una sola azione?
• il retry ha un limite, un backoff e una dead-letter queue?
• il provider riceve una risposta rapida anche quando il lavoro è lungo?
• l’ordine degli eventi viene assunto senza essere garantito?
• il deploy può partire due volte per lo stesso commit?
• una coda piena degrada con controllo oppure blocca il processo?
• ci sono metriche e log sufficienti per ricostruire il percorso?

Il valore dell’audit non è aggiungere un altro “sembra tutto ok”. È separare tre situazioni che spesso vengono confuse:

• il codice compila;
• il test principale passa;
• il sistema ha una strategia esplicita per duplicati, timeout e retry.

Sono cose diverse. Un repository può avere test verdi e non avere nessuna protezione contro la rielaborazione dello stesso evento. Può rispondere correttamente al primo webhook e fallire al quinto retry. Può avere una funzione handleWebhook() chiara, ma non dimostrare cosa succede quando due worker la eseguono contemporaneamente.

Con un audit Diagnostic di VibeInspect ricevi un verdetto sul rischio e le evidenze a livello di file e riga. Non una promessa generica e non una lista infinita di suggerimenti: l’obiettivo è capire se quel flusso è pronto per il carico e quali punti richiedono attenzione prima del go-live.

Cosa un linter non vede

Un linter controlla pattern locali: sintassi, import inutilizzati, variabili sospette, regole di stile, alcuni errori evidenti. È utile, ma non può dirti se un webhook viene processato due volte quando il provider ritenta la chiamata.

Non vede da solo che:

• il database salva il record dopo aver eseguito l’azione, invece che prima;
• due istanze possono superare insieme il controllo “evento già visto”;
• il job asincrono non conserva l’idempotency key;
• il timeout del reverse proxy è più breve del tempo di risposta dell’handler;
• un retry applicativo e un retry del provider si moltiplicano;
• un endpoint accetta eventi senza verificare firma, timestamp o replay;
• una modifica in una branch generata da Cursor attiva più pipeline del previsto.

Questi sono difetti di comportamento e di integrazione. Richiedono di leggere il repo come sistema: endpoint, code, transazioni, worker, configurazione, provider esterni e percorso di deploy. Il linter non emette quel verdetto. E nemmeno il fatto che l’app “funzioni sul mio computer”.

Il punto non è eliminare ogni rischio. È sapere quale rischio hai davanti, dove si manifesta e quali evidenze lo rendono credibile. Senza questo passaggio, la velocità degli agenti crea soltanto più superficie da verificare.

Cosa fare questa settimana

Prendi il repository che hai spedito con Cursor e scegli un solo flusso critico: webhook di pagamento, aggiornamento repository, deploy, sincronizzazione CRM o notifiche.

Poi fai questo esercizio:

1. annota ogni evento che può arrivare più di una volta;
2. indica dove viene salvata l’idempotency key;
3. misura quanto impiega l’handler a rispondere;
4. separa la ricezione del webhook dal lavoro lungo;
5. prova un retry duplicato e due richieste concorrenti;
6. controlla cosa succede se il worker si interrompe dopo aver compiuto l’azione ma prima di confermare il completamento;
7. conserva log e output della prova.

Se non sai rispondere a una di queste domande, non significa che hai fallito. Significa che ti manca un verdetto.

Carica il tuo ZIP su VibeInspect.ai e scegli Diagnostic se vuoi sapere quali file, righe ed evidenze rendono fragile il flusso. Se hai solo bisogno di uno score iniziale e non sai ancora dove guardare, parti da Snapshot.