Uložilo odoslanie s vypršaným časom vašu prácu?

Tlačidlo sa točí, karta zobrazuje chybu a formulár, ktorý ste desať minút vypĺňali, je preč. Neviete, či zápis prešiel skôr, než spojenie zomrelo. Práve zaobchádzanie s tou neznámou ako so zlyhaním vytvára duplicitné komentáre, dvojité objednávky a opakované tikety podpory.

Obnovujte v pevnom poradí: podržte text, nájdite výsledok a až potom rozhodnite, či je druhé odoslanie povolené.

Začnite textom a časovou pečiatkou

Skopírujte obsah zo stránky, skôr než sa dotknete čohokoľvek iného, vrátane konceptu, ktorý prehliadač ešte drží v poli. Zapíšte čas, stránku, na ktorej ste boli, a akciu, ktorú ste vykonali, pretože práve tieto tri údaje umožňujú zvyšok vyšetrovania. Ak je karta stále otvorená, nechajte ju otvorenú, kým si neprečítate záznam v sieti. Uložiť text nič nestojí a stratiť ho znamená stratiť celú úlohu.

Potom oddeľte dva druhy zlyhania, ktoré skutočne môžete pozorovať. Spojenie, ktoré spadlo uprostred požiadavky, a server, ktorý odpovedal chybou, vyzerajú v paneli siete odlišne, a len druhý vám niečo hovorí o rozhodnutí aplikácie.

Hľadajte výsledok vo vlastnom zobrazení aplikácie

Znova načítajte zobrazenie na čítanie, ktoré by výsledok ukázalo: zoznam komentárov, históriu objednávok, front tiketov alebo záznam, ktorý ste upravovali. Porovnávajte podľa účtu, cieľa, času a obsahu, nie podľa najnovšej položky, pretože niekto iný mohol písať po vás. Pri úlohe na pozadí vyhľadajte existujúcu referenciu a jej stav, namiesto toho, aby ste ako test konektivity vytvárali novú operáciu.

Ak tam výsledok je, ste hotoví a chyba patrí ceste odpovede, nie zápisu. Ak tam nie je, ponechajte možnosť, že ho aplikácia ešte nezapísala: úloha vo fronte, oneskorené zobrazenie na čítanie alebo oneskorená replika môžu úspešný zápis na chvíľu skryť.

Skôr než urobíte záver, dajte tomu určený druhý pohľad a poznamenajte čas oboch kontrol. Dve kontroly dvadsať sekúnd od seba sú oveľa slabší dôkaz než dve kontroly desať minút od seba.

Rozhodnite, či je druhé odoslanie bezpečné

Odpoveď závisí od operácie, nie od vašej trpezlivosti. HTTP oddeľuje metódy, ktoré možno opakovať s rovnakým zamýšľaným účinkom, od tých, ktoré nemožno, a neodporúča automatické opakovanie druhého druhu, ak nie je známe, že to sémantika dovoľuje. Vytvorenie komentára, zadanie objednávky a odoslanie platby zvyčajne patria do druhej skupiny, preto druhé úspešne vyzerajúce kliknutie nič nehovorí o prvom.

Ak spravujete klienta, použite mechanizmus opakovania alebo idempotencie, ktorý dokumentuje API, a pripútajte ho k tej istej logickej operácii, namiesto generovania nového kľúča pre každý pokus. Identifikátor požiadavky používaný na trasovanie nie je kľúčom na potlačenie duplicít, ak s ním server tak nezaobchádza.

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

Kľúč pomôže len vtedy, ak ho služba uloží k operácii a pri opakovaní vráti pôvodný výsledok. Otestujte toto správanie na stagingovom koncovom bode, skôr než sa naň v produkcii spoľahnete.

Zachyťte dôkazy, skôr než znova na niečo stlačíte

Uchovajte záznam siete, nie snímku obrazovky s chybou. Metóda požiadavky, URL, odpoveď alebo časový limit a čas, kedy sa to stalo, sú to, čo administrátor môže skorelovať so záznamami aplikácie. Exportujte alebo skopírujte záznam ako príkaz len vtedy, ak potom z kópie odstránite cookies, autorizačné hlavičky a akýkoľvek súkromný obsah. Nechajte svoju vlastnú reláciu nedotknutú a nikdy neprehrávajte zachytenú požiadavku s prihlasovacími údajmi ako skratku.

Položte vlastníkovi služby jednu konkrétnu otázku: podarila sa operácia s týmto obsahom v tomto čase a existuje na ňu referencia? Na túto otázku existuje odpoveď, zatiaľ čo "pokazil sa web" žiadnu nemá.

Zmyslom cvičenia je preukázať, že akcia nastala presne raz. Chybová správa, ktorú môžete zavrieť, nie je to isté ako záznam, ktorému môžete veriť, a ten druhý potrebujete, skôr než odošlete čokoľvek ďalšie.