Stripe mengingat permintaan Anda saat respons menghilang

Isi video ini

• Idempotensi berkaitan dengan efek yang dimaksud dari pengulangan suatu operasi. Stripe API v1 menambahkan kontrak pemutaran ulang respons yang disimpan yang didokumentasikan.
• Percobaan ulang tindakan logis yang sama menggunakan kunci dan parameter yang sama. Pertahankan kunci operasi di seluruh panggilan SDK atau mulai ulang aplikasi yang terpisah; tindakan yang benar-benar baru memerlukan kuncinya sendiri.
• Setelah eksekusi endpoint dimulai, Stripe API v1 menyimpan status dan isi permintaan pertama, termasuk kesalahan 500, dan mengembalikan respons yang disimpan tersebut pada percobaan ulang.
• Perubahan parameter dengan kunci yang sama menghasilkan ketidakcocokan. Kegagalan validasi dan konflik eksekusi bersamaan tidak menyimpan hasil idempoten untuk percobaan tersebut dan dapat dicoba ulang.
• Stripe menyimpan kunci API v1 setidaknya selama 24 jam dan dapat menghapusnya setelahnya. Batasi percobaan ulang jaringan yang belum terselesaikan hingga 24 jam pertama, lalu hentikan dan rekonsiliasi sebelum mengulangi operasi.
• Kesalahan 500 yang di-cache dapat terus diputar ulang setelah konektivitas pulih. Operasi asli mungkin memiliki efek samping; gunakan objek yang relevan, permintaan Dashboard, dan webhook untuk menentukan hasilnya.
• API v2 menggunakan semantik pemutaran ulang yang berbeda. Kunci tidak menetapkan pengiriman tepat satu kali secara universal untuk email, inventaris, dan setiap operasi basis data lokal.

Transkrip terjemahan

Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.

Apakah batas waktu membatalkan pembayaran Anda?

0:00 Anda berpikir batas waktu berarti pembayaran Anda gagal. Server dapat selesai sementara balasannya menghilang, membiarkan pembayaran Anda dengan percaya diri tidak menampilkan apa pun. Mengapa percobaan ulang dapat menagih lagi? Bagaimana Stripe mengingat sebuah percobaan? Kapan Anda harus berhenti mencoba ulang? Dan ingat satu detail buruk. Kesalahan yang diingat dapat bertahan lebih lama dari masalah jaringan.

0:17 Kita akan kembali ke sana. Ini adalah The Daily Diff, under the hood.

Apa yang diidentifikasi oleh kunci idempoten?

0:21 Idempotensi berarti mengulangi suatu operasi memiliki efek yang sama dengan melakukan nya sekali. Kunci idempoten memberi label satu tindakan logis. Stripe API versi satu mengenali label itu pada percobaan ulang dan memutar ulang respons yang disimpan. Bayangkan membeli kopi. Stripe menyelesaikan permintaan pembayaran Anda, dan responsnya hilang saat kembali pulang. Pelanggan melihat roda berputar. Bank mereka mungkin memiliki interpretasi yang lebih menarik. Permintaan buat yang tidak terlindungi dapat mengulangi efek samping.

Bagaimana kunci yang sama membuat percobaan ulang aman?

0:45 Lampirkan kunci unik sebelum percobaan pertama dan simpan untuk percobaan ulang. Jika aplikasi Anda dimulai ulang, pertahankan kunci itu dengan operasi dalam catatan Anda. Untuk Stripe API versi satu, setelah eksekusi endpoint dimulai, status dan isi permintaan pertama disimpan. Kirim kunci dan parameter yang sama lagi, dan Stripe mengembalikan respons yang disimpan. Kopi tetap di tempatnya sementara struknya dikirim lagi.

Apa sebenarnya yang disimpan Stripe?

1:07 Ini adalah kata-kata sebenarnya dari Stripe. Percobaan ulang dengan kunci yang sama mengembalikan respons yang disimpan, termasuk kesalahan lima ratus. Dokumentasi melakukan lebih banyak pekerjaan daripada pembantu percobaan ulang Anda yang diberi nama optimis. Pelanggan mengetuk lagi. Aplikasi Anda memutuskan apakah itu melanjutkan pembelian yang tertunda atau memulai yang lain. Kopi yang benar-benar baru mendapatkan kunci baru. Kunci baru untuk setiap percobaan ulang jaringan mengalahkan perlindungan.

1:27 Parameter yang berbeda dengan kunci yang sama memicu ketidakcocokan.

Apa yang terjadi ketika permintaan berubah?

1:30 Jika parameter gagal validasi, atau permintaan lain dengan kunci itu masih dieksekusi, Stripe tidak menyimpan hasil idempoten untuk percobaan itu. Permintaan tersebut dapat dicoba ulang. Permintaan yang bersaing mendapatkan konflik. Ini adalah aturan versi satu. Versi dua berperilaku berbeda. Header tidak dapat menjanjikan pengiriman tepat satu kali di seluruh sistem Anda. Email, inventaris, dan basis data Anda masing-masing memerlukan penanganan kegagalan.

1:52 Kunci melindungi operasi dalam cakupan yang didokumentasikan. Stripe menyimpan kunci versi satu setidaknya selama dua puluh empat jam dan dapat menghapusnya

Berapa lama hasil yang diingat aman untuk dicoba ulang?

1:59 setelahnya. Kunci yang dihapus dapat mengeksekusi permintaan baru. Pertahankan percobaan ulang yang belum terselesaikan dalam hari pertama. Setelah itu, hentikan dan rekonsiliasi hasil aslinya. Gunakan backoff eksponensial dan jitter untuk memberi server ruang bernapas. Jika tidak, percobaan ulang akan membentuk antrean di luar kedai kopi yang terbakar. Pustaka Stripe menangani percobaan ulang, tetapi periksa pengaturan default pustaka Anda. Kesalahan lengket itu adalah jebakannya.

Mengapa kesalahan yang diingat bisa terus muncul?

2:20 Respons lima ratus yang di-cache terus diputar ulang setelah konektivitas pulih. Operasi asli mungkin telah menghasilkan efek samping. Selesaikan hasilnya menggunakan objek, Dashboard, dan webhook. Kunci baru dapat mengulangi tindakan tersebut. Jika Anda lebih suka membaca ini daripada mendengarkan saya mengatakannya, diff akan sampai di kotak masuk Anda setiap pagi, gratis di the daily diff dot dev, tautan di bawah.

Apakah saya akan mengirimkan tombol percobaan ulang dengan kontrak ini?

2:39 Putusan, under the hood. SHIP IT. Saya akan mengirimkan kunci stabil dengan percobaan ulang terbatas dan rekonsiliasi, agar pelanggan mendapatkan kopi tanpa mendanai pendidikan sistem terdistribusi Anda. Dan itulah perbedaannya untuk hari ini. Saya Niko dari Axrisi. Gabungkan secara bertanggung jawab.

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