Sparade den tidsöverskridna inskickningen ditt arbete?

Knappen snurrar, fliken visar ett fel och formuläret du fyllde i i tio minuter är borta. Det du inte vet är om skrivningen nådde fram innan anslutningen dog. Att behandla det okända som ett misslyckande är hur dubblerade kommentarer, dubbla beställningar och upprepade supportärenden uppstår.

Återställ i fast ordning: behåll texten, hitta resultatet och avgör först då om en andra inskickning är tillåten.

Börja med texten och tidsstämpeln

Kopiera innehållet från sidan innan du rör något annat, inklusive det utkast som webbläsaren fortfarande håller i fältet. Skriv ned tiden, sidan du var på och åtgärden du utförde, eftersom det är just dessa tre detaljer som gör resten av undersökningen möjlig. Om fliken fortfarande är öppen, låt den vara öppen tills du har läst nätverksposten. Att spara texten kostar ingenting, och att förlora den kostar hela uppgiften.

Separera sedan de två feltyperna du faktiskt kan observera. En anslutning som bröts mitt i begäran och en server som svarade med ett fel ser olika ut i nätverkspanelen, och bara den andra säger något om applikationens beslut.

Leta efter resultatet i appens egen vy

Ladda om läs vyn som skulle visa resultatet: kommentarslistan, orderhistoriken, ärendekön eller posten du redigerade. Jämför på konto, mål, tid och innehåll i stället för på den senaste posten, eftersom någon annan kan ha skrivit efter dig. För ett bakgrundsjobb, slå upp den befintliga referensen och dess status i stället för att skapa en ny operation som anslutningstest.

Om resultatet finns där är du klar, och felet hör till svarsvägen och inte till skrivningen. Om det inte finns där, håll möjligheten öppen att applikationen ännu inte har bekräftat det: ett jobb i kö, en fördröjd läsvy eller en replik som släpar efter kan dölja en lyckad skrivning en stund.

Ge det en bestämd andra titt innan du drar en slutsats, och anteckna tiden för båda kontrollerna. Två kontroller med tjugo sekunders mellanrum är mycket svagare bevis än två kontroller med tio minuters mellanrum.

Avgör om en andra inskickning är säker

Svaret beror på operationen, inte på ditt tålamod. HTTP skiljer metoder som kan upprepas med samma avsedda effekt från dem som inte kan, och avråder från automatiska upprepningar av den andra typen om det inte är känt att semantiken tillåter det. Att skapa en kommentar, lägga en beställning och skicka en betalning hör vanligen till den andra gruppen, därför säger ett andra till synes lyckat klick ingenting om det första.

Om du underhåller klienten, använd den retry- eller idempotensmekanism som API:et dokumenterar, och knyt den till samma logiska operation i stället för att generera en ny nyckel för varje försök. En förfrågningsidentifierare som används för spårning är inte en nyckel för att undertrycka dubbletter om inte servern behandlar den som en sådan.

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

Nyckeln hjälper bara om tjänsten lagrar den mot operationen och returnerar det ursprungliga resultatet vid en upprepning. Testa det beteendet på en staging-endpunkt innan du förlitar dig på det i produktion.

Säkra bevis innan du trycker på något igen

Behåll nätverksposten i stället för en skärmbild av felet. Förfrågningsmetoden, URL:en, svaret eller tidsgränsen och tiden då det hände är det en administratör kan korrelera med applikationens register. Exportera eller kopiera posten som ett kommando bara om du därefter tar bort cookies, auktoriseringshuvuden och allt privat innehåll från kopian. Låt din egen session vara intakt, och spela aldrig upp en fångad förfrågan med inloggningsuppgifter som genväg.

Fråga tjänsteägaren en konkret fråga: lyckades operationen med detta innehåll vid denna tidpunkt, och finns det en referens för den? Den frågan har ett svar, medan "gick sidan sönder" inte har det.

Poängen med övningen är att fastställa att åtgärden inträffade exakt en gång. Ett felmeddelande du kan stänga är inte samma sak som en post du kan lita på, och den andra är vad du behöver innan du skickar något annat.