AI ajanı yeniden denemeden önce ne kadar beklemeli?

Yeniden deneme için doğru zaman nedir?

Araç çok fazla istek aldığını bildiriyor ve yirmi saniye beklemenizi istiyor. Ajan bunu genel bir hata sayıp hemen yeniden çağırırsa aynı yükü artırabilir. Diğer uçta, çok uzun bekleyip görev için ayrılan çağrı başlatma penceresini aşabilir. Doğru karar yalnızca tekrar edilip edilmeyeceği değildir; tekrarın en erken ve en geç hangi zamanda başlatılabileceğidir.

Buradaki dört senaryo birbirinden bağımsız sentetik okuma istekleridir. Gerçek servise çağrı yapılmaz. Araç sözleşmesi bu okuma işleminin tekrarına izin veriyor. Her senaryoda ilk yanıt t=10 saniyede alınmış, yerel politika bundan sonra en az beş saniye beklemeyi belirlemiş ve yeni çağrının t=60 anından önce başlamasını istemiştir. Bu son sınır çağrı başlangıcına aittir; tamamlanma garantisi değildir.

Retry-After, HTTP tarihi veya yanıt alındıktan sonra beklenecek saniye biçiminde bulunabilir. Saniye biçimi negatif olmayan ondalık tam sayıdır. MDN, 429 yanıtında bu alanı yeni isteğe kadar bekleme süresi olarak açıklar. Başlığın bulunması, her istemcinin onu otomatik uyguladığı veya işin sonraki denemede başarılı olacağı anlamına gelmez.Kaynak: MDN — Retry-After header

İki bekleme koşulundan daha geç olanı seçin

Saniye biçiminde başlığın yirmi dediğini düşünün. Yanıt t=10’da alındığı için sunucunun istediği en erken zaman t=30’dur. Yerel politika t=15 der. İkisini birlikte karşılayan ilk zaman daha geç olan t=30 olur. Başlık süresini ilk çağrının başladığı t=0’a eklemek, yanıt alındıktan sonra bekleme koşulunu yanlış uygular.

R3 bir süre değil, mutlak HTTP tarihidir. Ortak saat varsayımımız altında bu tarih t=40’a denk gelir. Yanıt alındıktan otuz saniye sonradır; kırk saniye daha beklemek anlamına gelmez. Gerçek sistemlerde saat uyumu ve tarih ayrıştırması ayrıca değerlendirilir. Bu alıştırma saat sapması veya ağ gecikmesi için verilmemiş bir düzeltme üretmez.

R4 negatif saniye yazdığı için bu örneğin başlık sözleşmesine uymaz. Onu otomatik sıfıra çevirmek veya mutlak değerini almak yeni bir politika icat eder. Eksik ve bozuk başlıkta ne yapılacağı uygulama tarafından ayrıca tanımlanmalıdır. Burada seçtiğimiz sonuç inceleme için durmaktır; rastgele bir yedek bekleme süresi uygulanmaz.

Zamanı hesaplayın, sonra bütçeyi sınayın

Dört bağımsız sentetik okuma yanıtı t=10’da alındı. Yerel asgari bekleme 5 saniye, yeni çağrı başlangıcı t<60. R1 Retry-After=20; R2=55; R3=Tue, 08 Sep 2026 09:00:40 GMT; R4=-2. t=0, 8 Eylül 2026 09:00:00 UTC. Geçerli başlıkta sunucu zamanını hesapla; yerel t15 ile daha geç olanı seç. Bütçe sınırını uygula. Bozuk başlığı düzeltme, çağrı yapma veya başarı iddia etme.

R1: yanıt sonrası 20 saniye bekleme, t30. R3: mutlak tarih t40; yanıt sonrası 30 saniye bekleme.
R2 t65 istediği için bu görev penceresinde başlatılamaz. R4 geçerli bir zaman üretmez.
İki planlanabilir, bir bütçe duruşu, bir başlık incelemesi. Gerçek yeni çağrı: 0.

Bütçe yetersizliğini aşmak için beklemeyi kısaltmak doğru değildir. R2’nin sunucu koşulu t=65 derken t=59’da çağırmak pencereye sığar görünür, fakat bekleme isteğini ihlal eder. Doğru devir kaydı, kalan pencerenin neden yetmediğini ve yeni bir görev penceresi kararının gerektiğini açıklar. Mevcut görevi sessizce uzatmayın.

Ayrıca yeniden deneme sayısı sınırı varsa zaman bakımından uygun bir çağrı o sınırdan yine kalabilir. Bu makale sayacı tüketen gerçek bir uygulama çalıştırmaz. Deneme planı hazırlandıktan sonra çağrı sayısı, izin, görevin iptal durumu ve işlem türü gibi mevcut koşullar uygulama tarafından yeniden değerlendirilmelidir.

Uyandıktan sonra koşulları yeniden okuyun

Planlanan zamanda çalışmak isteyen bir görev daha geç uyanabilir. R1 için t=30 planı yapılmışken işlem t=61’de yeniden ele alınırsa başlangıç penceresi artık kapanmıştır. Eski planın varlığı yeni çağrı için yeterli değildir. Gerçek başlatma anında saat ve görev durumu yeniden kontrol edilmelidir. Bekleme planı ile gerçekleşen çağrı zamanını farklı alanlarda tutun.

• Başlığın ham değerini ve ayrıştırılan türünü ayırın.
• Saniyeyi yanıtın alındığı ana bağlayın.
• Tarih biçimini ortak zaman çizelgesine dönüştürün.
• Yerel ve sunucu koşullarının ikisini de karşılayın.
• Gerçek başlatma anında pencereyi yeniden sınayın.

Bekleme süresi tamamlanmış olması, belirsiz bir yazma işlemini yeniden yapmaya yetmez. Biz yalnızca tekrarı izinli okuma senaryolarını seçtik. Kayıt oluşturan bir araçta önceki isteğin etkisi, tekilleştirme sözleşmesi ve aynı niyetin kimliği ayrı sorunlardır. Retry-After bu bilgileri sağlamaz; zaman koşulu diğer işlem koşullarının yerine geçmez.

Ajanın kullanıcıya verdiği bilgi de durumu doğru yansıtmalıdır. “İş tamamlandı” yerine “Yeni okuma t30’dan önce planlanmıyor” gibi gözlenen duruma bağlı bir açıklama kullanılabilir. Pencere bittiğinde eksik kalan bilgi, bekleme nedeni ve sonraki karar ihtiyacı kayda geçer. Yeni denemenin başarıya ulaşacağına dair söz verilmez.

Tam sınır ve sıfır bekleme

Yanıt yine t=10’da alınsın. Bir senaryoda Retry-After 50, başka bağımsız senaryoda 0 olsun. Yerel beş saniye koşulu ve t<60 başlangıç sınırı aynı kalsın. İki aday zamanı ve kararını bulun. Ardından sıfır başlığının neden hemen çağrı anlamına gelmediğini açıklayın.

50 saniye: aday t60; t<60 koşulu nedeniyle başlatılmaz. 0 saniye: sunucuya göre t10, yerel koşula göre t15; aday t15 ve pencere içinde. Sıfır sunucu beklemesi, yerel bekleme politikasını kaldırmaz.

Kendi akışınızda bekleme kararının hangi üç bilgiden üretildiğini yazın: yanıt zamanı, sunucu isteği ve uygulamanın başlangıç penceresi. Böylece yeniden deneme davranışı modelin aceleci yorumuna değil, açık zaman koşullarına dayanır.