Copilot ha seguito il bug. Ma il tuo webhook accetta ancora richieste duplicate

L’AI accelera il debugging, ma non decide quando il bug è davvero chiuso

Linus Torvalds ha raccontato una sessione di debugging difficile, nella quale un’AI ha svolto gran parte del lavoro ripetitivo: aggiungere codice di diagnostica, analizzare i risultati e continuare a indagare anche dopo aver dichiarato il problema quasi impossibile.

La fonte è Quoting Linus Torvalds, pubblicato il 22 agosto 2026. Il dettaglio interessante non è che l’AI abbia scritto codice. È che il lavoro utile sia arrivato da un ciclo di ipotesi, strumenti, osservazioni e verifiche. E che qualcuno abbia dovuto insistere per non fermarsi alla prima spiegazione plausibile.

Se hai spedito un prodotto generato o completato con un agente, la domanda è la stessa: il bug è davvero chiuso oppure il caso felice sta solo nascondendo un difetto nel flusso?

Cosa significa se il tuo codice l’ha scritto Copilot

Immagina un’applicazione che riceve webhook da un provider di pagamenti, CRM o comunicazioni. Hai usato Copilot per completare il controller, validare il payload e aggiornare l’ordine nel database.

Il test principale passa: arriva una richiesta, la firma sembra valida, l’ordine passa da pending a paid e il sistema risponde 200.

Il problema emerge quando lo stesso webhook viene consegnato due volte, magari perché il provider ritenta dopo un timeout o perché qualcuno ripete una richiesta già catturata. Se il codice verifica la firma ma non controlla un identificatore univoco dell’evento, la stessa operazione può essere eseguita più volte.

Questo è il buco tecnico: il webhook è autenticato, ma non è idempotente.

La conseguenza dipende dall’azione collegata all’evento. Potresti duplicare un rimborso, creare più record, inviare due email, incrementare due volte un saldo o generare una seconda spedizione. Non serve che la firma sia assente. Basta accettare una richiesta valida più di una volta.

Copilot può suggerire una soluzione perfettamente coerente con il codice esistente: verifica dell’header, parsing del JSON, chiamata al service e risposta positiva. Il problema non è necessariamente locale. È nella relazione tra retry, stato del database, chiave dell’evento e ordine delle operazioni.

Perché ora ti serve un audit del repository

Qui l’audit serve a ottenere un verdetto sul comportamento complessivo, non un altro suggerimento di codice.

La domanda è: se lo stesso webhook arriva due volte, il repository impedisce davvero che l’effetto di business venga applicato due volte?

Per rispondere bisogna ricostruire il percorso completo:

• quale endpoint riceve il webhook;
• come viene verificata la firma e con quale segreto;
• se il provider invia un event ID o una chiave equivalente;
• dove viene registrato l’evento già elaborato;
• se il controllo di duplicazione avviene prima dell’effetto di business;
• se esiste un vincolo univoco nel database;
• cosa succede quando due richieste identiche arrivano quasi nello stesso momento;
• come vengono gestiti timeout, retry ed errori dopo l’aggiornamento parziale.

Una ricerca testuale può trovare verifySignature, eventId o idempotency. Non dimostra che il controllo protegga davvero il punto critico. Il codice potrebbe verificare l’ID dopo aver già emesso un rimborso, salvare il record senza una constraint univoca oppure usare una cache che scade prima del retry del provider.

Un audit VibeInspect analizza lo ZIP del repository e restituisce un PDF con score e verdetto. Per un problema tecnico come questo, il piano Diagnostic è quello adatto: include file, righe ed evidenze per collegare route, verifica della firma, persistenza dell’evento e mutazione dei dati.

Il risultato utile non è “il webhook sembra protetto”. È una conclusione operativa: PASS, oppure FAIL, con la catena che mostra se una consegna duplicata può produrre due volte lo stesso effetto.

Questo è il passaggio che spesso manca nei progetti accelerati dall’AI. Copilot riduce il tempo per arrivare a un’implementazione plausibile. Non produce automaticamente la prova che il comportamento resti corretto sotto retry, concorrenza e timeout.

Il punto non è trovare una parola, ma dimostrare la sequenza

Un falso positivo è facile. Vedere che l’endpoint usa una firma HMAC non significa che il flusso sia completo. La firma garantisce l’autenticità del messaggio; non garantisce che l’evento venga elaborato una sola volta.

Anche trovare una tabella processed_events non basta. Devi verificare che:

1. il record venga creato prima dell’effetto non reversibile oppure dentro una transazione coerente;
2. l’identificatore dell’evento sia soggetto a un vincolo univoco;
3. due richieste concorrenti non possano superare entrambe il controllo iniziale;
4. un retry dopo un errore intermedio non lasci lo stato a metà;
5. il sistema distingua un duplicato già completato da un’elaborazione fallita che deve essere riprovata.

L’evidenza deve quindi seguire la sequenza reale: richiesta, autenticazione, deduplicazione, transazione, effetto di business e risposta. Se il report si ferma alla presenza della verifica della firma, non hai ancora un verdetto sulla duplicazione.

È qui che l’audit diventa il pezzo mancante tra “ho trovato un pattern” e “so cosa spedire”. Il problema non è che Copilot abbia prodotto una funzione sbagliata in modo evidente. È che una funzione localmente corretta può essere insufficiente quando il provider ritenta, il database risponde lentamente o due worker ricevono lo stesso evento.

Cosa un linter non vede

Un linter controlla regole locali: sintassi, tipi, import, formattazione e alcuni pattern noti. Può segnalare che una variabile non viene usata o che una chiamata manca di un parametro. Non conosce necessariamente l’invariante di business secondo cui un pagamento, un rimborso o una consegna devono avere un solo effetto.

Non ricostruisce sempre il rapporto tra controller, service, ORM e constraint del database. Non sa che il provider ritenta una richiesta quando il tuo endpoint supera il timeout. Non dimostra che due worker concorrenti non possano elaborare lo stesso event ID nello stesso istante.

Anche i test possono passare. Se ogni fixture contiene un solo webhook e ogni test invia una sola richiesta, il comportamento nominale è corretto. Ma manca il test che invia lo stesso evento due volte, il test che lo invia in parallelo e il test che interrompe il processo dopo il salvataggio prima dell’effetto successivo.

Il linter ti dice che il codice rispetta certe regole. L’audit ti dice se il repository mantiene una proprietà operativa importante quando il mondo reale non consegna gli eventi una sola volta e nell’ordine perfetto.

Cosa fare questa settimana

1. Scegli il webhook con l’effetto economico o operativo più importante.
2. Disegna la sequenza completa: ricezione, firma, deduplicazione, transazione e aggiornamento.
3. Verifica che ogni evento abbia un identificatore stabile e che il database lo renda univoco.
4. Invia lo stesso payload due volte e poi in parallelo: il risultato deve avere un solo effetto.
5. Simula un timeout dopo l’aggiornamento del database e verifica cosa accade al retry.
6. Controlla che la firma venga verificata sul payload originale, prima di qualsiasi trasformazione ambigua.
7. Se hai usato Copilot per costruire o modificare il flusso e non sai formulare un verdetto, fai un audit Diagnostic prima del prossimo rilascio.

Non devi smettere di usare Copilot. Devi smettere di confondere una patch plausibile con una prova di correttezza. L’AI può aiutarti a esplorare il bug; il tuo repository deve ancora dimostrare che il caso difficile è gestito.

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