Naaalala ng Stripe ang iyong kahilingan kapag nawala ang tugon

Ang sakop ng video na ito

• Ang idempotency ay nauugnay sa nilalayon na epekto ng pag-uulit ng isang operasyon. Nagdaragdag ang Stripe API v1 ng dokumentadong kontrata ng na-save na replay ng tugon.
• Ang muling pagsubok ng parehong lohikal na pagkilos ay gumagamit ng parehong key at mga parameter. Panatilihin ang key ng operasyon sa magkahiwalay na tawag sa SDK o pag-restart ng application; ang isang tunay na bagong pagkilos ay nangangailangan ng sarili nitong key.
• Matapos magsimula ang pagpapatupad ng endpoint, ini-save ng Stripe API v1 ang status at body ng unang kahilingan, kabilang ang 500 na error, at ibinabalik ang na-save na tugon sa mga pagsubok muli.
• Ang mga binagong parameter na may parehong key ay gumagawa ng hindi pagtutugma. Ang mga pagkabigo sa pagpapatunay at mga salungatan sa sabay-sabay na pagpapatupad ay hindi nagse-save ng idempotent na resulta para sa pagtatangka na iyon at maaaring subukang muli.
• Pinapanatili ng Stripe ang mga key ng API v1 nang hindi bababa sa 24 na oras at maaaring i-prune ang mga ito pagkatapos. Limitahan ang hindi nalutas na mga retry ng network sa unang 24 na oras, pagkatapos ay huminto at ayusin bago ulitin ang operasyon.
• Ang isang naka-cache na 500 ay maaaring patuloy na mag-replay matapos bumalik ang konektibidad. Ang orihinal na operasyon ay maaaring may mga side effect; gamitin ang nauugnay na object, kahilingan sa Dashboard at mga webhook upang matukoy ang resulta nito.
• Gumagamit ang API v2 ng iba't ibang semantika ng replay. Hindi nagtatatag ang isang key ng unibersal na eksaktong-isang paghahatid para sa email, imbentaryo at bawat lokal na operasyon ng database.

Isinaling transcript

Isinalin mula sa orihinal na salaysay sa English. Ang available na audio at mga caption ay kinokontrol ng YouTube.

Nakansela ba ng timeout ang iyong bayad?

0:00 Inakala mong nangangahulugan ang timeout na nabigo ang iyong bayad. Maaaring matapos ang server habang nawawala ang tugon, na iniiwan ang iyong checkout na buong kumpiyansang nagpapakita ng wala. Bakit maaaring maningil muli ang isang retry? Paano naaalala ng Stripe ang isang pagsubok? Kailan mo dapat ihinto ang pagsubok muli? At tandaan ang isang pangit na detalye. Ang isang naaalalang error ay maaaring mas matagal pa kaysa sa problema sa network.

0:17 Babalikan natin iyan. Ito ang The Daily Diff, sa ilalim ng hood.

Ano ang kinikilala ng isang idempotency key?

0:21 Ang idempotency ay nangangahulugang ang pag-uulit ng isang operasyon ay may parehong nilalayon na epekto tulad ng paggawa nito nang isang beses. Ang isang idempotency key ay nagmamarka ng isang lohikal na pagkilos. Kinikilala ng API bersyon isa ng Stripe ang label na iyon sa mga retry at nagre-replay ng na-save na tugon. Ilarawan ang pagbili ng kape. Kinukumpleto ng Stripe ang iyong kahilingan sa pagbabayad, at nawawala ang tugon na pabalik sa bahay. Nakikita ng customer ang isang spinner. Maaaring may mas kapana-panabik na interpretasyon ang kanilang bangko. Ang isang hindi protektadong kahilingan sa paglikha ay maaaring ulitin ang side effect.

Paano ginagawang ligtas ng parehong key ang isang retry?

0:45 Mag-attach ng isang natatanging key bago ang unang pagsubok at panatilihin ito para sa mga retry. Kung mag-restart ang iyong application, panatilihin ang key na iyon kasama ang operasyon sa iyong mga tala. Para sa bersyon isa API ng Stripe, sa sandaling magsimula ang pagpapatupad ng endpoint, ang status at body ng unang kahilingan ay nai-save. Ipadala muli ang parehong key at mga parameter, at ibabalik ng Stripe ang na-save na tugon. Mananatili ang kape habang muling naglalakbay ang resibo nito.

Ano ang eksaktong ini-save ng Stripe?

1:07 Narito ang aktwal na salita ng Stripe. Ang mga retry na may parehong key ay nagbabalik ng na-save na tugon, kabilang ang limang daang error. Ang dokumentasyon ay gumagawa ng mas maraming trabaho kaysa sa iyong optimistikong pinangalanang retry helper. Muling mag-tap ang customer. Nagpasya ang iyong app kung ipagpapatuloy nito ang nakabinbing pagbili o magsisimula ng isa pa. Ang isang tunay na bagong kape ay makakakuha ng bagong key. Ang isang sariwang key para sa bawat retry ng network ay tatalunin ang proteksyon.

1:27 Ang iba't ibang parameter na may parehong key ay nagpapalitaw ng hindi pagtutugma.

Ano ang mangyayari kapag nagbago ang kahilingan?

1:30 Kung mabigo ang mga parameter sa pagpapatunay, o may iba pang kahilingan na may key na iyon ay patuloy pa ring pinapatakbo, hindi nagse-save ang Stripe ng idempotent na resulta para sa pagtatangka na iyon. Ang mga kahilingang iyon ay maaaring subukang muli. Ang isang racing request ay makakakuha ng conflict. Ito ang mga panuntunan ng bersyon isa. Magkaiba ang pag-uugali ng bersyon dalawa. Hindi maaaring mangako ang isang header ng eksaktong isang paghahatid sa buong iyong system. Ang email, imbentaryo at ang iyong database ay bawat isa ay nangangailangan ng paghawak sa pagkabigo.

1:52 Pinoprotektahan ng key ang operasyon sa loob ng dokumentadong saklaw nito. Pinapanatili ng Stripe ang mga key ng bersyon isa nang hindi bababa sa dalawampu't apat na oras at maaaring i-prune

Gaano katagal ligtas na subukang muli ang naaalalang resulta?

1:59 ang mga ito pagkatapos. Ang isang na-prune na key ay maaaring magsagawa ng bagong kahilingan. Panatilihin ang hindi nalutas na mga retry sa loob ng unang araw. Higit pa doon, huminto at ayusin ang orihinal na resulta. Gumamit ng exponential backoff at jitter upang bigyan ng puwang ang server. Kung hindi man, ang mga retry ay bumubuo ng isang pila sa labas ng isang nasusunog na coffee shop. Hinahawakan ng mga library ng Stripe ang mga retry, ngunit tingnan ang mga default ng iyong library. Ang malagkit na error na iyon ang catch.

Bakit patuloy na bumabalik ang isang naaalalang error?

2:20 Ang isang naka-cache na limang daang tugon ay patuloy na nagre-replay matapos bumalik ang konektibidad. Ang orihinal na operasyon ay maaaring nakagawa ng mga side effect. Lutasin ang resulta nito gamit ang mga object, ang Dashboard at mga webhook. Ang isang bagong key ay maaaring ulitin ang pagkilos. Kung mas gugustuhin mong basahin ito kaysa pakinggan akong sabihin ito, ang diff ay dumarating sa iyong inbox tuwing umaga, libre sa the daily diff dot dev, link sa ibaba.

Magpapadala ba ako ng pindutan ng retry gamit ang kontratang ito?

2:39 Hatol, sa ilalim ng hood. Ipadala. Ipadala ko ang matatag na key na may mga bounded retry at pagkakasundo, upang makakuha ang mga customer ng kape nang hindi pinopondohan ang iyong distributed systems education. At iyan ang diff para sa araw na ito. Ako si Niko mula sa Axrisi. Pagsamahin nang responsable.

Mga Pinagmulan

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor