Il tuo repo Replit riceve due volte lo stesso webhook?

L’AI aiuta a fare il lavoro pesante, ma non consegna il verdetto

Linus Torvalds ha raccontato una sessione di debugging molto complessa in cui l’AI ha svolto gran parte del lavoro ripetitivo: ha aggiunto codice di diagnostica, analizzato i risultati e continuato a collaborare anche dopo aver dichiarato più volte che il problema sembrava impossibile da risolvere. Il punto non è che l’agente avesse sempre ragione. È che poteva essere utile solo dentro un ciclo di verifica insistente.

La fonte è Quoting Linus Torvalds, pubblicato il 22 agosto 2026.

Per chi ha costruito e spedito un prodotto con Replit, la lezione è diretta: il codice può funzionare durante il test manuale e fallire quando il sistema ripete una richiesta, perde una connessione o riceve lo stesso evento più volte.

Il buco tecnico di oggi è il replay di webhook: lo stesso evento viene accettato ed eseguito più di una volta perché il backend non verifica l’idempotenza.

Cosa significa se il tuo codice l’ha scritto Replit

Immagina un’applicazione Replit collegata a Stripe, GitHub, Shopify o a un altro servizio esterno. Un webhook comunica che è successo qualcosa: un pagamento è riuscito, un ordine è stato creato, una pull request è stata aggiornata.

Il tuo endpoint riceve il payload e fa il lavoro previsto:

1. legge l’evento;
2. verifica — forse — la firma;
3. aggiorna il database;
4. invia una mail o una notifica;
5. restituisce 200 OK.

Il problema nasce quando il provider ritenta la consegna. Può succedere per un timeout, una risposta persa, un errore temporaneo o una connessione interrotta dopo che il server ha già completato l’operazione.

Se il tuo endpoint esegue di nuovo tutto senza controllare un identificativo univoco, lo stesso evento può:

• creare due ordini;
• accreditare due volte un saldo;
• inviare più email al cliente;
• duplicare una fattura;
• avviare due volte un job costoso;
• modificare lo stato di una risorsa in modo inatteso.

Un’implementazione fragile può sembrare perfetta:

POST /api/webhooks/payment
→ aggiorna ordine
→ registra pagamento
→ invia conferma
→ 200 OK

Manca però la domanda fondamentale: “Questo event_id è già stato elaborato?”.

La protezione corretta richiede almeno un identificativo stabile, una registrazione persistente degli eventi già processati e una transazione coerente tra controllo e aggiornamento. Non basta conservare un flag nella memoria del processo: dopo un riavvio o con più istanze, quel dato può sparire o non essere condiviso.

Replit non è il problema. Il problema è spedire un endpoint che gestisce eventi esterni senza definire cosa deve accadere quando lo stesso evento arriva due volte.

Perché ora ti serve un audit: il comportamento reale sta tra più componenti

Un audit VibeInspect serve a trasformare il dubbio “forse il provider ritenta” in una risposta verificabile sul tuo repository.

Nel caso del replay di webhook, l’analisi deve seguire il percorso completo:

• dove viene ricevuto il webhook;
• quale campo identifica univocamente l’evento;
• se la firma del provider viene verificata prima di agire;
• dove vengono salvati gli eventi già elaborati;
• se il controllo avviene prima dell’operazione sensibile;
• se il controllo e l’aggiornamento sono atomici;
• cosa succede quando due richieste identiche arrivano quasi nello stesso momento;
• se job asincroni, code o retry possono eseguire di nuovo lo stesso lavoro;
• se l’endpoint restituisce errore dopo aver già modificato lo stato.

La risposta utile non è “l’endpoint ha una gestione dei webhook”. È qualcosa di più concreto: l’evento viene identificato tramite event_id, ma il valore non è vincolato univocamente nel database; due richieste concorrenti possono superare il controllo prima della registrazione; la conferma email parte fuori dalla transazione e può essere duplicata.

Questa è la differenza tra osservare una feature e avere un verdetto. Il flusso principale può funzionare per settimane. Il difetto emerge soltanto quando il provider riprova, quando il processo si riavvia o quando due consegne arrivano insieme.

L’audit prende il tuo repository ZIP, analizza codice e configurazione con specialisti AI e produce un PDF con score, verdetto ed evidenze. Non è un pentest, non corregge il codice e non sostituisce una revisione umana. Serve a dirti dove il comportamento non è sufficientemente definito.

Per un possibile replay di webhook, il piano adatto è Diagnostic: ti servono file, righe ed evidenze tecniche per correggere il flusso con priorità.

Cosa un linter non vede

Un linter può verificare sintassi, tipi, import e alcuni pattern locali. Non può sapere se lo stesso evento esterno viene elaborato due volte.

Il codice può essere perfettamente valido:

@app.post("/webhooks/payment")
def payment_webhook(event):
    update_order(event["data"])
    send_confirmation(event["data"])
    return {"ok": True}

Il linter non conosce la semantica di event_id. Non sa se update_order() è ripetibile. Non sa se send_confirmation() può partire due volte. Non sa se il provider ritenta dopo un timeout e non sa se due worker eseguono lo stesso messaggio contemporaneamente.

Anche un test funzionale può ingannarti. Se invii un webhook una volta e controlli che l’ordine venga aggiornato, hai verificato il percorso felice. Non hai dimostrato che la seconda consegna sia ignorata, che una richiesta concorrente non duplichi il risultato o che un errore dopo il commit non provochi un nuovo effetto collaterale.

Il problema è temporale e distribuito. Sta nella relazione tra provider, endpoint, database, coda e job asincrono. Per questo non si risolve cercando soltanto una riga “sbagliata”.

Cosa fare questa settimana

Se hai spedito con Replit, fai questo controllo prima del prossimo rilascio:

1. Elenca tutti i webhook ricevuti da servizi esterni.
2. Identifica il campo univoco di ogni evento.
3. Verifica che l’evento venga autenticato prima di eseguire qualsiasi azione.
4. Crea una tabella o un vincolo persistente per gli eventi già elaborati.
5. Rendi atomici il controllo dell’evento e il cambio di stato principale.
6. Invia due richieste identiche quasi contemporaneamente e controlla il risultato.
7. Simula un timeout dopo l’aggiornamento del database ma prima della risposta HTTP.
8. Verifica che retry, code e job asincroni conservino l’identificativo originale.
9. Controlla che email, rimborsi, crediti e altri effetti esterni siano idempotenti o protetti.
10. Aggiungi metriche e log senza registrare payload sensibili o segreti.

Il test decisivo è semplice: lo stesso webhook può arrivare due volte senza produrre due effetti?

“Il pagamento funziona” non è un verdetto. “L’evento evt_123 viene accettato una sola volta, le richieste concorrenti non duplicano l’ordine e i retry non reinviano la conferma” è un verdetto.

Se non sai ancora quanto è robusto il flusso, carica il tuo repo su VibeInspect.ai e ottieni un primo score con Snapshot. Se hai già visto retry, doppie notifiche o aggiornamenti duplicati, scegli Diagnostic per ricevere evidenze su file, righe e percorso tecnico.

Replit ti aiuta a passare rapidamente dall’idea al prodotto. Ma il codice non è pronto perché ha superato una demo: è pronto quando sai come reagisce al secondo evento, al timeout e all’errore che arriva nel momento peggiore.