Stripe mengingati permintaan anda apabila respons hilang

Apa yang diliputi video ini

• Idempoten melibatkan kesan yang dimaksudkan untuk mengulang operasi. Stripe API v1 menambah kontrak ulangan respons yang disimpan yang didokumenkan.
• Cubaan semula tindakan logik yang sama menggunakan kunci dan parameter yang sama. Kekalkan kunci operasi merentas panggilan SDK atau permulaan semula aplikasi yang berasingan; tindakan yang benar-benar baru memerlukan kuncinya sendiri.
• Selepas pelaksanaan titik akhir bermula, Stripe API v1 menyimpan status dan badan permintaan pertama, termasuk ralat 500, dan mengembalikan respons yang disimpan itu pada cubaan semula.
• Parameter yang diubah dengan kunci yang sama menghasilkan ketidakpadanan. Kegagalan pengesahan dan konflik pelaksanaan serentak tidak menyimpan hasil idempoten untuk percubaan itu dan boleh dicuba semula.
• Stripe mengekalkan kunci API v1 sekurang-kurangnya 24 jam dan boleh memotongnya selepas itu. Hadkan percubaan semula rangkaian yang belum selesai kepada 24 jam pertama, kemudian berhenti dan selesaikan sebelum mengulang operasi.
• Ralat 500 yang disimpan dalam cache boleh terus diulang selepas ketersambungan pulih. Operasi asal mungkin mempunyai kesan sampingan; gunakan objek yang berkaitan, permintaan Papan Pemuka dan webhook untuk menentukan hasilnya.
• API v2 menggunakan semantik ulangan yang berbeza. Kunci tidak menetapkan penghantaran tepat sekali secara universal untuk e-mel, inventori dan setiap operasi pangkalan data tempatan.

Transkrip terjemahan

Diterjemahkan daripada penceritaan asal Bahasa Inggeris. Audio dan kapsyen yang tersedia dikawal oleh YouTube.

Adakah tamattempo membatalkan pembayaran anda?

0:00 Anda fikir tamattempo bermakna pembayaran anda gagal. Pelayan boleh selesai semasa balasan hilang, meninggalkan pembayaran anda memaparkan apa-apa dengan yakin. Mengapa cubaan semula boleh mengenakan caj lagi? Bagaimana Stripe mengingati percubaan? Bilakah anda perlu berhenti mencuba semula? Dan ingat satu perincian yang tidak menyenangkan. Ralat yang diingati boleh bertahan lebih lama daripada masalah rangkaian.

0:17 Kita akan kembali kepada perkara itu. Ini adalah The Daily Diff, di sebalik tabir.

Apakah yang dikenal pasti oleh kunci idempoten?

0:21 Idempoten bermakna mengulang operasi mempunyai kesan yang sama seperti melakukan sekali. Kunci idempoten melabelkan satu tindakan logik. Stripe API versi satu mengenali label itu pada cubaan semula dan mengulang respons yang disimpan. Bayangkan membeli kopi. Stripe menyelesaikan permintaan pembayaran anda, dan respons hilang dalam perjalanan pulang. Pelanggan melihat roda berputar. Bank mereka mungkin mempunyai tafsiran yang lebih menarik. Permintaan "create" yang tidak dilindungi boleh mengulang kesan sampingan.

Bagaimana kunci yang sama menjadikan cubaan semula selamat?

0:45 Lampirkan kunci unik sebelum percubaan pertama dan simpannya untuk cubaan semula. Jika aplikasi anda dimulakan semula, kekalkan kunci itu dengan operasi dalam rekod anda. Untuk Stripe API versi satu, setelah pelaksanaan titik akhir bermula, status dan badan permintaan pertama disimpan. Hantar kunci dan parameter yang sama sekali lagi, dan Stripe mengembalikan respons yang disimpan. Kopi kekal di tempatnya manakala resitnya dihantar semula.

Apa sebenarnya yang Stripe simpan?

1:07 Ini adalah perkataan sebenar Stripe. Cubaan semula dengan kunci yang sama mengembalikan respons yang disimpan, termasuk ralat lima ratus. Dokumentasi melakukan lebih banyak kerja daripada pembantu cuba semula anda yang dinamakan secara optimis. Pelanggan mengetuk lagi. Aplikasi anda memutuskan sama ada itu menyambung semula pembelian yang belum selesai atau memulakan yang lain. Kopi yang benar-benar baru mendapat kunci baru. Kunci baru untuk setiap cubaan semula rangkaian mengalahkan perlindungan.

1:27 Parameter yang berbeza dengan kunci yang sama mencetuskan ketidakpadanan.

Apa yang berlaku apabila permintaan berubah?

1:30 Jika parameter gagal pengesahan, atau permintaan lain dengan kunci itu masih berjalan, Stripe tidak menyimpan hasil idempoten untuk percubaan itu. Permintaan-permintaan itu boleh dicuba semula. Permintaan yang berlumba-lumba mendapat konflik. Ini adalah peraturan versi satu. Versi dua berkelakuan berbeza. Pengepala tidak boleh menjanjikan penghantaran tepat sekali di seluruh sistem anda. E-mel, inventori dan pangkalan data anda masing-masing memerlukan pengendalian kegagalan.

1:52 Kunci melindungi operasi dalam skop yang didokumenkan. Stripe mengekalkan kunci versi satu sekurang-kurangnya dua puluh empat jam dan boleh memotongnya

Berapa lama hasil yang diingati selamat untuk dicuba semula?

1:59 selepas itu. Kunci yang dipotong boleh melaksanakan permintaan baru. Kekalkan cubaan semula yang belum selesai dalam hari pertama. Selepas itu, berhenti dan selesaikan hasil asal. Gunakan "exponential backoff" dan "jitter" untuk memberi ruang kepada pelayan. Jika tidak, cubaan semula akan membentuk barisan di luar kedai kopi yang terbakar. Perpustakaan Stripe mengendalikan cubaan semula, tetapi semak lalai perpustakaan anda. Ralat yang melekat itu adalah perangkapnya.

Mengapa ralat yang diingati boleh terus kembali?

2:20 Respons lima ratus yang disimpan dalam cache terus diulang selepas ketersambungan pulih. Operasi asal mungkin telah menghasilkan kesan sampingan. Selesaikan hasilnya menggunakan objek, Papan Pemuka dan webhook. Kunci baru boleh mengulang tindakan itu. Jika anda lebih suka membaca ini daripada mendengar saya mengatakannya, perbezaan itu sampai di peti masuk anda setiap pagi, percuma di the daily diff dot dev, pautan di bawah.

Adakah saya akan menghantar butang cuba semula dengan kontrak ini?

2:39 Keputusan, di sebalik tabir. Hantar. Saya akan menghantar kunci stabil dengan cubaan semula dan penyelesaian yang terhad, supaya pelanggan mendapat kopi tanpa membiayai pendidikan sistem teragih anda. Dan itulah perbezaan untuk hari ini. Saya Niko dari Axrisi. Gabungkan dengan bertanggungjawab.

Sumber

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