Cloudflare, Durable Objects çağrılarına otomatik yeniden denemeler ekledi ve hata maliyetine göre ayırdı

Bir Durable Object çağrısı ağ hatasıyla sonuçlandığında, geliştiriciler daha önce bu çağrıyı yeniden gönderip göndermemeye kendileri karar vermek zorunda kalıyordu. 5 Kasım 2026'dan itibaren bu yeniden denemelerin bir kısmını Cloudflare runtime'ı gerçekleştiriyor: fetch() ve stub üzerinden yapılan RPC çağrılarındaki belirli başarısızlıkları otomatik olarak yeniden deniyor. Uygulama kodu açısından artık temel soru daha kesin: Belirli bir metodun ikinci kez güvenle çalıştırılması mümkün mü?

Yanıt, bağlantının nerede kesildiğine bağlı. Runtime, varsayılan olarak çift yürütmeye karşı korumayı sürdürerek bazı çağrıları otomatik olarak yeniden dener. Teslimatın sonucu belirsizse aynı istek kimliğini kullanır ve nesne ilk denemeyi zaten aldıysa tekrarı reddeder. Açıkça retryable() olarak işaretlenmiş bir metodun davranışı farklıdır: İlk deneme nesneye ulaşmış olsa bile metot yeniden çalıştırılabilir. Bu nedenle bu işaret yalnızca hem durum hem de yan etkiler açısından yeniden denenmesi güvenli işlemlere uygulanmalıdır.

Runtime tam olarak neyi yeniden deniyor?

Cloudflare'ın 5 Kasım tarihli duyurusuna göre yeniden denemeler, bir Worker veya başka bir Durable Object tarafından yapılan Durable Object fetch() ve RPC çağrılarını kapsıyor. Stub üzerinden yapılan çağrılarda varsayılan olarak ilk denemeye ek en fazla dört yeniden deneme bulunuyor; çağrının başlamasından 10 saniyeden daha geç bir zamanda yeni deneme başlatılmıyor.

Koşul, hatanın .retryable özelliğine sahip olmasıdır. Örneğin nesne yeniden başlatıldığı veya taşındığı için istek nesneye ulaşmamış olabilir. Bağlantı kesildiğinde ve nesnenin isteği alıp almadığı belirlenemediğinde de runtime yeniden deneyebilir. Nesne isteği zaten aldıysa aynı kimlikle gönderilen tekrar reddedilir. Runtime, Durable Object kodunun fırlattığı hataları, .overloaded hatalarını ve 500 gibi HTTP yanıtlarını yeniden denemez: Bunlar teslimat hatası değil, işleyicinin yanıtıdır.

Teslimatın yeniden denenmesi neden işlemin yeniden denenmesiyle aynı değildir?

İsteğin yeniden iletilmesi tek başına metodun ikinci kez çalıştırılacağı anlamına gelmez. Sonucun belirsiz olduğu durumda runtime isteği aynı kimlikle gönderir; nesne ilk denemeyi aldıysa tekrarı reddeder. Bu, örneğin tek bir ağ hatası yüzünden yeniden ödeme alınmasını veya kayıt oluşturulmasını engelleyerek normal modda metodun tekrar çalıştırılmasını önler.

Metot, cloudflare:durable-objects içindeki retryable() ile işaretlendiğinde sınır değişir. Bu durumda, ilk deneme başlamış olabilecek olsa bile nesnenin metodu yeniden çalıştırmasına izin verilir. Cloudflare iki örnek veriyor: Bir ürüne belirli bir miktar atamak idempotenttir; miktarı bir artırmak ise değildir. İlk işlemin tekrarı aynı değeri ayarlar, ikincisinin tekrarıysa bir birim daha ekler.

Yalnızca depolama alanındaki son durumu değil, metodun tüm etkilerini de kontrol edin. Tekrar çalıştırma yeni bir ödeme oluşturuyor, mesaj gönderiyor veya harici bir eylem başlatıyorsa Durable Object içindeki durumun aynı kalması yeniden denemeyi güvenli kılmaz. Bu işaret, tekrarın sonucun anlamını değiştirmediği ve yan etkileri çoğaltmadığı durumlarda kullanılmalıdır.

Açık idempotans nerede işe yarar?

Bir değeri ayarlamak, durumun anlık görüntüsünü yazmak veya bir alanı bilinen bir değere güncellemek çoğu zaman tekrarlansa da aynı sonucu verir. Bu tür metotlarda retryable(), işleme başladıktan sonra meydana gelen bir bağlantı kesintisine rağmen çağrının başarıyla tamamlanmasını sağlayabilir.

“Artır”, “bir tane daha oluştur”, “tahsil et” ve “gönder” işlemleri genellikle başka bir koruma gerektirir. Yeniden çalıştırmaya izin vermeden önce iş işleminin yinelenenleri tanıyabildiğinden veya tekrarın ikinci bir etki yaratmayacak şekilde tasarlandığından emin olun. Fonksiyonun adı hiçbir şeyi garanti etmez: Metot içindeki tüm durum değişikliklerini ve harici eylemleri kontrol edin.

retryable() sınırlı bir işleve sahiptir: İlk çağrının ulaşıp ulaşmadığı belirlenemediğinde yürütmenin tekrarlanmasına izin verir. Runtime'ın tepki verdiği hata türlerini değiştirmez ve deneme sayısını artırmaz. İşaret fonksiyona uygulanır; metodun üzerine yazılmış veya sarmalanmış sürümü de açıkça işaretlenmedikçe bu işareti otomatik olarak devralmaz.

Mevcut bir projede neleri kontrol etmeli?

Gözden geçirilmesi en olası nokta, Durable Objects çağrılarının etrafındaki özel yeniden deneme döngüleridir. Artık her denemeye runtime'ın yeniden denemeleri de eklenebileceğinden, toplam çağrı sayısı yalnızca uygulamanın belirlediği sayıdan fazla olabilir. Cloudflare, kendi kodunuz yeniden denemeleri yönetiyorsa uygulamanın deneme sayısını azaltmanızı veya stub için maxRetries: 0 ayarlamanızı öneriyor.

Belirli bir stub'ın sınırları, get() veya getByName() çağrılırken belirlenir. maxRetries parametresi ilk denemeden sonra sıfır ile on arasında yeniden deneme sayısı belirler; timeoutMs ise yeni denemelerin başlatılmayacağı süreyi, 500 ile 60.000 milisaniye arasında ayarlar. Bu ayarlar söz konusu stub üzerinden yapılan çağrılara uygulanır. retryable() ve retry nesnesi için Wrangler 4.158.0 veya daha yeni bir sürüm gerekir.

Yararlı bir gözden geçirme için her çağrı hakkında üç soru sorun: Durumu birden fazla kez değiştirebilir mi; harici yan etkileri tekrarlar mı; uygulamanın kendi yeniden deneme politikası var mı? Ardından bu stub'ın varsayılan değerleri mi yoksa özel sınırları mı kullanması gerektiğine karar verin. İdempotent metotlarda açıkça işaretlemeyi ayrıca değerlendirebilirsiniz; diğerlerinde korumayı sürdürün ve ilk denemenin sonucu bilinmediğinde hata işleme sürecini kontrol edin.

Sonuç: Sorumluluk metodun sınırına taşınıyor

Otomatik yeniden deneme, ağ iletişimi mantığının bir kısmını uygulama kodundan çıkarıyor; ancak yürütmenin tekrar edilip edilemeyeceğine karar vermek hâlâ işlemin niteliğine bağlı. Runtime, aktarımı güvenle yeniden deneyebilir ve çağrının yürütülüp yürütülmediğini bilmiyorsa durabilir. Geliştirici ise durum değişikliklerini veya yan etkileri çoğaltmayacağını açıkça onaylayarak metodun yeniden denenmesine izin verebilir.

Bu nedenle güncellemeyi, taşıma katmanıyla işleyici arasındaki sözleşmede yapılan bir değişiklik olarak değerlendirmek gerekir. Önce kendi yeniden deneme döngülerinizi ve yan etkilerin tekrar edilip edilemeyeceğini kontrol edin; ardından gerekli stub'larda sınırları belirleyin. Böylece kısa süreli kesintilere karşı yerleşik dayanıklılığı, ikinci kez çalıştırılmasının gerçek bir bedeli olan işlemler üzerindeki denetimle birleştirebilirsiniz.