Nai-save ba talaga ng na-timeout na submit na iyon ang trabaho mo?

Umiikot ang button, may error sa tab, at nawala ang form na sampung minuto mong pinunan. Ang hindi mo alam ay kung nakarating ang pagsulat bago namatay ang koneksyon. Ang ituring na kabiguan ang hindi pagkaalam na iyon ang paraan ng paglitaw ng doble-dobleng komento, doble-dobleng order at paulit-ulit na support ticket.

Mag-recover sa takdang pagkakasunod-sunod: itago ang teksto, hanapin ang resulta, at saka lamang magpasya kung pinapayagan ang ikalawang submit.

Magsimula sa teksto at timestamp

Kopyahin ang nilalaman mula sa pahina bago hawakan ang anupaman, kasama ang anumang draft na hawak pa ng browser sa field. Isulat ang oras, ang pahinang kinaroroonan mo at ang ginawang aksyon, dahil ang tatlong detalyeng ito ang nagpapaging-posible sa natitirang pagsisiyasat. Kung bukas pa ang tab, hayaan itong bukas hanggang mabasa mo ang network entry. Walang gastos ang pag-save ng teksto, at ang pagkawala nito ay gastos ng buong gawain.

Pagkatapos, paghiwalayin ang dalawang anyo ng pagkabigo na talagang mapapansin mo. Ang koneksyong naputol sa gitna ng request at ang server na sumagot ng error ay magkaiba sa network panel, at ang pangalawa lang ang may sinasabi tungkol sa desisyon ng app.

Hanapin ang resulta sa sariling view ng app

I-reload ang reading view na magpapakita ng resulta: ang listahan ng komento, kasaysayan ng order, pila ng ticket o ang record na ine-edit mo. Itugma sa account, destinasyon, oras at nilalaman sa halip na sa pinakabagong entry, dahil may ibang nakasulat pagkatapos mo. Para sa background job, hanapin ang umiiral na reference at ang kalagayan nito sa halip na gumawa ng bagong operasyon bilang pagsubok sa koneksyon.

Kung naroon ang resulta, tapos ka na at ang error ay para sa daan ng sagot, hindi sa pagsulat. Kung wala, panatilihin ang posibilidad na hindi pa ito nakumpirma ng app: ang job sa pila, naantalang reading view o nahuhuling replica ay maaaring magtago ng matagumpay na pagsulat sa loob ng ilang sandali.

Bigyan ito ng takdang ikalawang tingin bago magbigay ng konklusyon, at itala ang oras ng dalawang pagsusuri. Ang dalawang pagsusuring may pagitan ng dalawampung segundo ay mas mahinang ebidensya kaysa dalawang pagsusuring may pagitan ng sampung minuto.

Magpasya kung ligtas ang ikalawang submit

Depende ang sagot sa operasyon, hindi sa pasensya mo. Hinihiwalay ng HTTP ang mga method na maaaring ulitin na may parehong nilalayong epekto mula sa mga hindi, at pinapayuhan laban sa awtomatikong pag-ulit ng pangalawang uri maliban kung alam na pinapayagan ito ng semantika. Ang paggawa ng komento, pag-order at pagpapadala ng bayad ay karaniwang nasa ikalawang grupo, kaya ang ikalawang klik na tila matagumpay ay walang sinasabi tungkol sa una.

Kung ikaw ang nagpapanatili ng client, gamitin ang retry o idempotency na dokumentado ng API, at ikabit ito sa parehong lohikal na operasyon sa halip na gumawa ng bagong key para sa bawat pagtatangka. Ang request identifier na ginagamit para sa tracing ay hindi duplicate-suppression key maliban kung tinatrato ito ng server bilang ganoon.

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

Tumutulong lang ang key kung iniimbak ito ng serbisyo kasama ng operasyon at ibinabalik ang orihinal na resulta kapag inulit. Subukan ang pag-uugaling iyon sa isang staging endpoint bago umasa rito sa produksyon.

Kolektahin ang ebidensya bago pindutin muli ang anuman

Itago ang network entry sa halip na screenshot ng error. Ang method ng request, URL, sagot o timeout at ang oras na nangyari ito ang maaaring iugnay ng administrator sa mga record ng app. I-export o kopyahin ang entry bilang command lamang kung aalisin mo pagkatapos ang cookies, authorization header at anumang pribadong nilalaman mula sa kopya. Iwanang buo ang sarili mong session, at huwag kailanman i-replay ang nahuli na request na may credential bilang shortcut.

Tanungin ang may-ari ng serbisyo ng isang tiyak na tanong: nagtagumpay ba ang operasyon sa nilalamang ito sa oras na ito, at may reference ba para rito? May sagot ang tanong na iyon, samantalang ang "nasira ba ang site" ay wala.

Ang layunin ng pagsasanay ay tiyakin na nangyari ang aksyon nang eksaktong isang beses. Ang error message na maaari mong isara ay hindi katulad ng record na maaasahan mo, at ang pangalawa ang kailangan mo bago magpadala ng anupaman.