Entegrasyon rehberleri · 2026-09-22
Muse Spark Contributor'da timeout ve bağlantı hataları yönetimi
429 dışındaki hata sınıflarını, yani zaman aşımı ve bağlantı kopmalarını ele alır; bu hataların 429'dan farklı bir yeniden deneme mantığı gerektirdiğini anlatır.
429 ile timeout aynı aileden değildir
Muse Spark Contributor'da 429 yeniden deneme yazısında anlatıldığı gibi, kota tükenmesi HTTP durum koduyla açıkça işaretlenir ve bekleme süresi çoğu zaman yanıt başlığından okunabilir. Zaman aşımı ve bağlantı kopması ise farklı bir hata ailesidir: istek sunucuya ulaşmış olabilir, ulaşmamış olabilir veya yanıt yolda kaybolmuş olabilir; bu belirsizlik 429'daki netlikten farklı bir yaklaşım gerektirir.
Bu farkı gözden kaçırıp her hatayı aynı sabit bekleme süresiyle yeniden denemek, timeout durumunda gereksiz yere uzun süre beklemenize veya bağlantı sorunlarında çok erken pes etmenize yol açabilir.
Timeout'ta isteğin durumu belirsizdir
Bir istek zaman aşımına uğradığında, sunucunun isteği hiç almadığını, aldığını ama yanıtı üretemediğini veya yanıtı üretip size ulaştıramadığını ayırt edemezsiniz. Yan etkisi olmayan bir isteği (yalnızca metin üretimi) doğrudan yeniden denemek genellikle güvenlidir. Ancak isteğin bir yan etkisi varsa (örneğin bir veri katkısı gönderimi), aynı isteği kör biçimde tekrar göndermek, işlemin iki kez gerçekleşmesi riskini taşır.
Bağlantı kopması (connection reset, DNS hatası) genellikle ağ katmanında bir sorunu işaret eder ve isteğin sunucuya hiç ulaşmamış olma ihtimali daha yüksektir; bu tür hatalarda doğrudan yeniden deneme, kota hatasına göre daha düşük risklidir.
- Timeout: isteğin durumu belirsizdir, yan etkisi olan istekleri körü körüne tekrar göndermeyin.
- Bağlantı kopması: genellikle isteğin sunucuya ulaşmadığını gösterir, yeniden deneme daha düşük risklidir.
- 429'daki net bekleme süresinin aksine, timeout'ta üstel geri çekilme (exponential backoff) kullanın.
Üst sınır koymadan yeniden denemeyin
Timeout ve bağlantı hatalarında da 429'da olduğu gibi bir üst deneme sınırı gerekir; aksi hâlde kalıcı bir ağ sorunu, sonsuz bir yeniden deneme döngüsüne dönüşebilir. Sınıra ulaşıldığında hatayı sessizce yutmak yerine açıkça bildirmek, sorunun fark edilmesini sağlar.
Sık sorulan sorular
Timeout hatasında da 429'daki gibi sabit bir bekleme süresi mi kullanmalıyım?
Hayır. 429'da bekleme süresi çoğu zaman yanıt başlığından net biçimde okunur; timeout'ta böyle bir bilgi yoktur, bu yüzden artan bekleme süreleriyle (üstel geri çekilme) ilerlemek daha uygundur.
Yan etkisi olan bir isteği timeout sonrası yeniden denemek güvenli mi?
Kesin değildir; isteğin sunucuda gerçekten işlenip işlenmediği belirsizdir. Yan etkisi olan istekler için, mümkünse isteği tekrar göndermeden önce işlemin gerçekleşip gerçekleşmediğini ayrı bir sorguyla kontrol etmek daha güvenlidir.