Uložilo odeslání s vypršelým časem vaši práci?

Tlačítko se točí, karta zobrazuje chybu a formulář, který jste deset minut vyplňovali, je pryč. Nevíte, zda zápis proběhl dřív, než spojení zemřelo. Právě zacházení s touto neznámou jako se selháním vytváří duplicitní komentáře, dvojité objednávky a opakované tikety podpory.

Obnovujte v pevném pořadí: podržte text, najděte výsledek a teprve potom rozhodněte, zda je druhé odeslání povoleno.

Začněte textem a časovým razítkem

Zkopírujte obsah ze stránky, než se dotknete čehokoli dalšího, včetně konceptu, který prohlížeč ještě drží v poli. Zapište čas, stránku, na které jste byli, a akci, kterou jste provedli, protože právě tyto tři údaje umožňují zbytek vyšetřování. Pokud je karta stále otevřená, nechte ji otevřenou, dokud si nepřečtete záznam v síti. Uložit text nic nestojí a ztratit ho znamená ztratit celý úkol.

Poté oddělte dva druhy selhání, které skutečně můžete pozorovat. Spojení, které spadlo uprostřed požadavku, a server, který odpověděl chybou, vypadají v panelu sítě odlišně, a jen druhý z nich vám něco říká o rozhodnutí aplikace.

Hledejte výsledek ve vlastním zobrazení aplikace

Znovu načtěte zobrazení pro čtení, které by výsledek ukázalo: seznam komentářů, historii objednávek, frontu tiketů nebo záznam, který jste upravovali. Porovnávejte podle účtu, cíle, času a obsahu, nikoli podle nejnovější položky, protože někdo jiný mohl psát po vás. U úlohy na pozadí vyhledejte existující referenci a její stav, místo abyste jako test konektivity vytvářeli novou operaci.

Pokud tam výsledek je, jste hotovi a chyba patří k cestě odpovědi, ne k zápisu. Pokud tam není, ponechte možnost, že ho aplikace ještě nezapsala: úloha ve frontě, zpožděné zobrazení pro čtení nebo opožděná replika mohou úspěšný zápis na chvíli skrýt.

Než uděláte závěr, dejte tomu určený druhý pohled a poznamenejte čas obou kontrol. Dvě kontroly dvacet sekund od sebe jsou mnohem slabší důkaz než dvě kontroly deset minut od sebe.

Rozhodněte, zda je druhé odeslání bezpečné

Odpověď závisí na operaci, ne na vaší trpělivosti. HTTP odděluje metody, které lze opakovat se stejným zamýšleným účinkem, od těch, které nelze, a nedoporučuje automatické opakování druhého druhu, pokud není známo, že to sémantika dovoluje. Vytvoření komentáře, zadání objednávky a odeslání platby obvykle patří do druhé skupiny, a proto druhé úspěšně vypadající kliknutí nic neříká o tom prvním.

Pokud spravujete klienta, použijte mechanismus opakování nebo idempotence, který API dokumentuje, a přivažte ho ke stejné logické operaci, místo abyste pro každý pokus generovali nový klíč. Identifikátor požadavku používaný pro trasování není klíčem pro potlačení duplicit, pokud s ním server tak nezachází.

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

Klíč pomůže jen tehdy, když ho služba uloží k operaci a při opakování vrátí původní výsledek. Otestujte toto chování na stagingovém koncovém bodu, než se na něj v produkci spolehnete.

Zachyťte důkazy, než znovu na něco stisknete

Uchovejte záznam sítě, ne snímek obrazovky s chybou. Metoda požadavku, URL, odpověď nebo časový limit a čas, kdy k tomu došlo, jsou to, co administrátor může zkorelovat se záznamy aplikace. Exportujte nebo zkopírujte záznam jako příkaz jen tehdy, když pak z kopie odstraníte cookies, autorizační hlavičky a jakýkoli soukromý obsah. Nechte svou vlastní relaci nedotčenou a nikdy neopakujte zachycený požadavek s přihlašovacími údaji jako zkratku.

Položte vlastníkovi služby jednu konkrétní otázku: proběhla operace s tímto obsahem v tomto čase úspěšně a existuje pro ni reference? Na tuto otázku existuje odpověď, zatímco "rozbil se web" žádnou nemá.

Smyslem cvičení je prokázat, že akce proběhla právě jednou. Chybová zpráva, kterou můžete zavřít, není totéž jako záznam, kterému můžete věřit, a ten druhý potřebujete, než odešlete cokoli dalšího.