AWS SDK varsayılan retry davranışı 1 Kasım 2026'da değişiyor: DynamoDB deneme sayısı 9'dan 4'e düşüyor

AWS, 1 Kasım 2026'da SDK'lerindeki varsayılan retry davranışını değiştirecek; dev.to'da yayımlanan bir yazı, bu değişikliğin kağıt üzerinde küçük görünse de kısmi arıza durumlarında servislerin davranışını sessizce yeniden şekillendirebileceğini savunuyor. Aynı yazı, son tarihten önce yeni varsayılanların gerçek üretim trafiğine ne yapacağını ölçmek için geliştirilmiş, retrylens adlı açık kaynak bir Java kütüphanesini tanıtıyor.

1 Kasım 2026'da ne değişiyor

dev.to yazısına göre değişiklik; Java, Python, JavaScript, Go ve PHP için AWS SDK'lerinin yanı sıra CLI'yı kapsıyor ve şu değerleri ayarlıyor:

• Çoğu servis için maksimum deneme sayısı 4'ten 3'e düşüyor.
• DynamoDB için maksimum deneme sayısı 9'dan 4'e düşüyor.
• Geçici hatalar için temel gecikme 100 ms'den 50 ms'ye iniyor.
• Throttling için temel gecikme 500 ms'den 1000 ms'ye çıkıyor.
• LimitExceededException ve STS IdpCommunicationErrorException yeniden denenebilir hale geliyor.

Yazar, asıl önemli satırın DynamoDB olduğunu belirtiyor; çünkü bu servis, SDK pes etmeden önce dokuz denemeye kadar izin veren uzun süredir var olan bir servis bazlı geçersiz kılma ayarına sahip. Bu derin retry bütçesine yaslanarak kısa throttling patlamalarını sessizce atlatan yazma yolları, üst sınır dört olduğunda bugün başarılı olan çağrıların başarısız olmaya başladığını görebilir.

Etkinin neden önceden görülmesi zor

Yazı, ne AWS duyurusunun ne de uygulama loglarının asıl önemli soruyu yanıtlayamadığına dikkat çekiyor: yeni varsayılanlar belirli bir iş yüküne ne yapardı? Duyuru, bir servisin gece saatlerindeki throttling desenleri hakkında hiçbir şey bilmiyor; SDK'nin retry döngüsü de dışarıdan büyük ölçüde görünmez — çağıran taraf ara denemeleri değil, yalnızca nihai başarıyı ya da başarısızlığı gözlemler.

AWS SDK for Java 2.44 ve sonrasını kullanan Java kullanıcıları AWS_NEW_RETRIES_2026=true ayarını yaparak erken katılabilir, ancak yazar bunun her şeyi bir kerede değiştirdiğini ve zarar verip vermediğini öğrenmenin tek yolunun etkinleştirip gözlemlemek olduğunu belirtiyor.

retrylens denemeleri kaydediyor ve yeni varsayılanları yeniden oynatıyor

Bu boşluğu kapatmak için yazar, retrylens'i Apache 2.0 lisansıyla Maven Central ve GitHub'da yayımladı; kütüphaneyi zorunlu bir runtime bağımlılığı olmayan yaklaşık 600 satır Java kodu olarak tanımlıyor. Kütüphane, herhangi bir AWS SDK v2 client'ına tek bir ExecutionInterceptor ekliyor, her denemeyi sınırlı bir ring buffer'a kaydediyor ve ardından Kasım 2026 varsayılanlarının aynı trafiğe ne yapacağını simüle ediyor.

Simülatör projeksiyonunu yalnızca kaydedilmiş deneme sonuçlarından hesaplıyor: hiçbir isteği yeniden göndermiyor, AWS ile iletişim kurmıyor ve kimlik bilgisi gerektirmiyor — yazar, canlı bir uygulamaya karşı çalıştırmayı güvenli kılanın da bu olduğunu söylüyor. Entegrasyon tek bir builder çağrısından ibaret: interceptor'ı client'ın overrideConfiguration'ı üzerinden kaydedin, ardından mevcut raporu STANDARD_2026 retry moduyla üretilmiş bir önizlemeyle karşılaştırın ve farkı okuyun. AWS SDK provided dependency olarak bildirildiği için uygulamalar halihazırda kullandıkları sürümde kalıyor; 2.20 veya daha yenisi öneriliyor ve retry değerleri 2.44 ve sonrası için kalibre edilmiş durumda.

Yazı, sentetik bir DynamoDB, S3 ve SQS iş yükünden temsili bir anlık görüntü sunuyor: mevcut varsayılanlar altında 6 başarısızlıkla sonuçlanan 1.428 çağrı, 2026 varsayılanları altında 27 başarısızlığa yükseliyor olarak projeksiyonlanıyor. Bu fark — 21 ekstra başarısızlık ve 223 daha az deneme — çoğunlukla, sürekli throttling altında DynamoDB PutItem'ın retry'larını daha erken tüketmesinden kaynaklanıyor. Yazarın vurguladığı nokta şu: somut bir sayı, gerçek bir kararı destekliyor — yazma kapasitesini artırmak, işlem bazında bir retry geçersiz kılma ayarı yapmak ya da bu düşüşü bilinçli olarak kabul etmek.

Belirtilen sınırlamalar

Yazı, aracın sınırları konusunda açık sözlü. Standart mod retry kotasını — sürekli arıza altında retry'ları bastırabilen token bucket'ı — modellemiyor, dolayısıyla simülatör yeni modun ne sıklıkta retry yapacağını olduğundan fazla gösterebilir. Canlı jitter'ı modellemiyor ve backoff zamanlamasını tek bir örneklenmiş sonuç yerine full jitter'ın istatistiksel beklentisi olarak raporluyor. Ayrıca istekleri hiçbir zaman yeniden göndermediği için sonuçlar kaydedilmiş trafik karışımını yansıtıyor — trafik değişirse ölçüm yeniden yapılmalı.

Yazarın şu anki önerileri

Ekipler kütüphaneyi benimsesin ya da benimesin, yazı üç adımdan birini öneriyor: uygulamayı bir hafta boyunca staging ortamında AWS_NEW_RETRIES_2026=true ile çalıştırıp CloudWatch başarısızlık metriklerini önceki haftayla karşılaştırmak; retrylens'i otuz dakika boyunca üretim trafiğinin bir canary'sine karşı çalıştırıp farkı okumak; ya da AWS_RETRY_MODE=legacy ayarını şimdi üretimde açıkça belirlemek, böylece 1 Kasım geldiğinde vazgeçme seçeneği zaten yerinde olur ve geçiş, son tarih tarafından dayatılmak yerine planlı bir şekilde programlanabilir.

Neden önemli

Retry yapılandırması, çoğu ekibin hiç incelemediği bir varsayılan ve değişiklikleri yalnızca kısmi arıza altında — throttling, geçici hatalar, bozulan bağımlılıklar — ortaya çıkıyor; tam da sessiz davranış değişikliklerinin teşhis edilmesinin en zor olduğu anda. DynamoDB'nin dokuz denemeden dörde indirilmesi en keskin uç; bazı sürekli throttling senaryolarını nihai başarısızlıktan görünür hatalara dönüştürüyor. Daha geniş ders Java'yı aşıyor: SDK retry derinliğine örtük olarak bağımlı olan her iş yükü, henüz kapasiteyi ayarlama, legacy davranışı sabitleme ya da yeni bir başarısızlık profilini bilinçli olarak kabul etme zamanı varken ölçümlenmeli.