+− THE DAILY DIFFdev & AI news
SHIP IT

Yanıt kaybolduğunda Stripe isteğinizi hatırlar

Sunucu işlemi tamamladıktan sonra bir zaman aşımı, bir ödemeyi belirsiz bırakabilir.

Sunucu işlemi tamamladıktan sonra bir zaman aşımı, bir ödemeyi belirsiz bırakabilir. Bu 'Under the Hood' açıklayıcısı, istikrarlı işlem anahtarlarını, kaydedilen yanıtın tekrarını, parametre ve eşzamanlılık limitlerini, saklama süresini ve sonuç uzlaştırmasını göstermek için Stripe API v1'in belgelenmiş idempotentlik sözleşmesini kullanır.

Yazılı sürümü oku (İngilizce) ↗

Bu video neleri kapsar

  • İdempotentlik, bir işlemi tekrarlamanın hedeflenen etkisi ile ilgilidir. Stripe API v1, belgelenmiş bir kaydedilen yanıtın tekrarı sözleşmesi ekler.
  • Aynı mantıksal eylemin tekrar denenmesi aynı anahtarı ve parametreleri kullanır. İşlem anahtarını ayrı SDK çağrıları veya uygulama yeniden başlatmaları arasında sürdürün; gerçekten yeni bir eylem kendi anahtarına ihtiyaç duyar.
  • Uç nokta yürütmesi başladıktan sonra, Stripe API v1, 500 hataları dahil olmak üzere ilk isteğin durumunu ve gövdesini kaydeder ve bu kaydedilen yanıtı tekrar denemelerde döndürür.
  • Aynı anahtarla değiştirilen parametreler bir uyuşmazlık üretir. Doğrulama hataları ve eşzamanlı yürütme çakışmaları, o deneme için idempotent bir sonuç kaydetmez ve tekrar denenebilir.
  • Stripe API v1 anahtarlarını en az 24 saat saklar ve sonrasında budayabilir. Çözülmemiş ağ tekrar denemelerini ilk 24 saatle sınırlayın, ardından işlemi tekrarlamadan önce durun ve uzlaştırın.
  • Önbelleğe alınmış bir 500 hatası, bağlantı sağlandıktan sonra bile tekrar tekrar oynatılabilir. Orijinal işlemin yan etkileri olabilir; sonucunu belirlemek için ilgili nesneyi, Kontrol Paneli isteğini ve webhook'ları kullanın.
  • API v2 farklı tekrar oynatma semantiği kullanır. Bir anahtar, e-posta, envanter ve her yerel veritabanı işlemi için evrensel olarak tam olarak bir kez teslimat sağlamaz.

Çevrilmiş deşifre

Orijinal İngilizce anlatımdan çevrilmiştir. Mevcut ses ve altyazılar YouTube tarafından kontrol edilir.

Zaman aşımı ödemenizi mi iptal etti?

0:00 Zaman aşımının ödemenizin başarısız olduğu anlamına geldiğini düşünüyorsunuz. Sunucu, yanıt kaybolurken işlemi bitirebilir, ödeme işleminizi güvenle kesinlikle hiçbir şey göstermeden bırakır. Bir tekrar denemesi neden tekrar ücretlendirebilir? Stripe bir denemeyi nasıl hatırlar? Tekrar denemeyi ne zaman bırakmalısınız? Ve aklınızda bir kötü detayı tutun. Hatırlanan bir hata, ağ sorunundan daha uzun sürebilir.

0:17 Buna geri döneceğiz. Burası The Daily Diff, perde arkası.

Bir idempotentlik anahtarı neyi tanımlar?

0:21 İdempotentlik, bir işlemi tekrarlamanın, işlemi bir kez yapmakla aynı hedeflenen etkiye sahip olması anlamına gelir. Bir idempotentlik anahtarı, bir mantıksal eylemi etiketler. Stripe'ın API sürüm biri, bu etiketi tekrar denemelerde tanır ve kaydedilmiş bir yanıtı tekrar oynatır. Bir kahve satın aldığınızı hayal edin. Stripe ödeme isteğinizi tamamlar ve yanıt geri dönerken kaybolur. Müşteri bir dönen işaret görür. Bankaları daha heyecan verici bir yoruma sahip olabilir. Korumasız bir oluşturma isteği yan etkiyi tekrarlayabilir.

Aynı anahtar bir tekrar denemesini nasıl güvenli hale getirir?

0:45 İlk denemeden önce benzersiz bir anahtar ekleyin ve tekrar denemeler için saklayın. Uygulamanız yeniden başlarsa, o anahtarı kayıtlarınızdaki işlemle birlikte koruyun. Stripe'ın sürüm bir API'si için, uç nokta yürütmesi başladıktan sonra, ilk isteğin durumu ve gövdesi kaydedilir. Aynı anahtarı ve parametreleri tekrar gönderin, Stripe kaydedilen yanıtı döndürür. Kahve yerinde kalır, makbuzu tekrar yolculuk ederken.

Stripe tam olarak ne kaydeder?

1:07 İşte Stripe'ın gerçek ifadesi. Aynı anahtarla yapılan tekrar denemeleri kaydedilmiş yanıtı döndürür, beş yüz hataları dahil. Belgeler, iyimser olarak adlandırılmış tekrar deneme yardımcınızdan daha fazla iş yapar. Müşteri tekrar dokunur. Uygulamanız bunun bekleyen satın almayı sürdürüp sürdürmeyeceğine veya başka bir tane başlatıp başlatmayacağına karar verir. Gerçekten yeni bir kahve yeni bir anahtar alır. Her ağ tekrar denemesi için yeni bir anahtar, korumayı etkisiz hale getirir.

1:27 Aynı anahtarla farklı parametreler bir uyuşmazlığı tetikler.

İstek değiştiğinde ne olur?

1:30 Parametreler doğrulama hatası verirse veya o anahtarla başka bir istek hala yürütülüyorsa, Stripe o deneme için idempotent bir sonuç kaydetmez. Bu istekler tekrar denenebilir. Yarışan bir istek çakışma alır. Bunlar sürüm bir kurallarıdır. Sürüm iki farklı davranır. Bir başlık, sisteminizde tam olarak bir kez teslimat sözü veremez. E-posta, envanter ve veritabanınızın her biri hata yönetimine ihtiyaç duyar.

1:52 Anahtar, işlemi belgelenmiş kapsamı içinde korur. Stripe sürüm bir anahtarlarını en az yirmi dört saat saklar ve sonrasında budayabilir.

Hatırlanan sonuç ne kadar süreyle tekrar denemek için güvenlidir?

1:59 Budanmış bir anahtar yeni bir isteği yürütebilir. Çözülmemiş tekrar denemelerini ilk gün içinde tutun. Bunun ötesinde, durun ve orijinal sonucu uzlaştırın. Sunucuya nefes alma alanı vermek için üstel geri çekilme ve titreşim kullanın. Aksi takdirde tekrar denemeler yanan bir kahve dükkanının dışında bir sıra oluşturur. Stripe'ın kütüphaneleri tekrar denemeleri yönetir, ancak kütüphanenizin varsayılanlarını kontrol edin. Bu yapışkan hata yakalamaktır.

Hatırlanan bir hata neden sürekli geri gelebilir?

2:20 Önbelleğe alınmış beş yüz yanıtı, bağlantı sağlandıktan sonra bile tekrar oynatılmaya devam eder. Orijinal işlem yan etkiler üretmiş olabilir. Nesneleri, Kontrol Panelini ve webhook'ları kullanarak sonucunu çözün. Yeni bir anahtar eylemi tekrarlayabilir. Bunu duymaktansa okumayı tercih ederseniz, diff her sabah gelen kutunuza düşer, daily diff dot dev'de ücretsiz, bağlantı aşağıda.

Bu sözleşmeyle bir tekrar dene düğmesi yayınlar mıydım?

2:39 Karar, perde arkası. Gönderin. Sınırlı tekrar denemeleri ve uzlaştırma ile istikrarlı anahtarlar gönderirdim, böylece müşteriler dağıtılmış sistemler eğitiminizi finanse etmeden kahve alırlar. Ve bugünün farkı bu. Ben Axrisi'den Niko. Sorumlu bir şekilde birleştirin.

Kaynaklar

  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

İlgili videolar