Quell’invio scaduto ha davvero salvato il tuo lavoro?

Il pulsante gira, la scheda mostra un errore e il modulo che hai impiegato dieci minuti a compilare è sparito. Quello che non sai è se la scrittura è arrivata prima che la connessione morisse. Trattare quell’incognita come un fallimento è il modo in cui nascono commenti duplicati, ordini doppi e ticket di assistenza ripetuti.

Recupera in un ordine fisso: conserva il testo, trova il risultato e solo dopo decidi se è consentito un secondo invio.

Parti dal testo e dal timestamp

Copia il contenuto dalla pagina prima di toccare qualsiasi altra cosa, compresa ogni bozza che il browser tiene ancora nel campo. Annota l’ora, la pagina in cui eri e l’azione che hai compiuto, perché sono proprio questi tre dettagli a rendere possibile il resto dell’indagine. Se la scheda è ancora aperta, lasciala aperta finché non hai letto la voce di rete. Salvare il testo non costa nulla, perderlo costa l’intera attività.

Poi separa le due forme di guasto che puoi davvero osservare. Una connessione caduta a metà richiesta e un server che ha risposto con un errore appaiono diversi nel pannello di rete, e solo la seconda ti dice qualcosa sulla decisione dell’app.

Cerca il risultato nella vista dell’app stessa

Ricarica la vista di lettura che mostrerebbe il risultato: l’elenco dei commenti, la cronologia degli ordini, la coda dei ticket o il record che stavi modificando. Confronta per account, destinazione, ora e contenuto invece che per la voce più recente, perché qualcun altro potrebbe aver scritto dopo di te. Per un’attività in background, cerca il riferimento esistente e il suo stato invece di creare una nuova operazione come test di connettività.

Se il risultato c’è, hai finito e l’errore appartiene al percorso della risposta, non alla scrittura. Se non c’è, tieni aperta la possibilità che l’app non l’abbia ancora confermato: un’attività in coda, una vista di lettura ritardata o una replica in ritardo possono nascondere per un po’ una scrittura riuscita.

Dagli un secondo sguardo definito prima di trarre una conclusione e annota l’ora di entrambi i controlli. Due controlli a venti secondi di distanza sono una prova molto più debole di due controlli a dieci minuti di distanza.

Decidi se un secondo invio è sicuro

La risposta dipende dall’operazione, non dalla tua pazienza. HTTP separa i metodi che possono essere ripetuti con lo stesso effetto voluto da quelli che non possono, e sconsiglia i tentativi automatici del secondo tipo salvo che la semantica sia nota per consentirlo. Creare un commento, effettuare un ordine e inviare un pagamento di solito stanno nel secondo gruppo, per questo un secondo clic che sembra riuscito non dice nulla sul primo.

Se gestisci il client, usa il meccanismo di nuovo tentativo o di idempotenza documentato dall’API, e collegalo alla stessa operazione logica invece di generare una nuova chiave per ogni tentativo. Un identificatore di richiesta usato per la tracciatura non è una chiave di soppressione dei duplicati, a meno che il server non lo tratti come tale.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

La chiave aiuta solo se il servizio la memorizza insieme all’operazione e restituisce il risultato originale a una ripetizione. Prova questo comportamento su un endpoint di staging prima di affidarti ad esso in produzione.

Raccogli prove prima di premere di nuovo qualcosa

Conserva la voce di rete invece di uno screenshot dell’errore. Il metodo della richiesta, l’URL, la risposta o il timeout e l’ora in cui è successo sono ciò che un amministratore può correlare con i registri dell’app. Esporta o copia la voce come comando solo se poi rimuovi dalla copia i cookie, le intestazioni di autorizzazione e qualsiasi contenuto privato. Lascia intatta la tua sessione e non riprodurre mai una richiesta catturata con credenziali come scorciatoia.

Chiedi al proprietario del servizio una domanda precisa: l’operazione con questo contenuto a quest’ora è riuscita ed esiste un riferimento? Quella domanda ha una risposta, mentre "il sito si è rotto" non ce l’ha.

Il senso dell’esercizio è stabilire che l’azione è avvenuta esattamente una volta. Un messaggio di errore che puoi chiudere non è la stessa cosa di un registro di cui puoi fidarti, e il secondo è ciò di cui hai bisogno prima di inviare qualsiasi altra cosa.