n8n’de yeniden deneme: aynı işi ikinci kez yapmadan toparlan

Bir otomasyon bir bildirimi göndermek ister, fakat yanıt beklerken zaman aşımına uğrar. Akışta kırmızı hata görürsün. Aynı adımı yeniden çalıştırmak kolaydır; ama bildirim ilk denemede gönderildiyse alıcı iki mesaj alabilir. Bu nedenle yeniden deneme tasarımı yalnızca kaç saniye bekleneceğiyle ilgili değildir. Aynı işin ne olduğunu, hangi durumda tekrar edilebileceğini ve belirsiz bir sonucun nasıl araştırılacağını da tanımlamak gerekir.

Hata türüne göre karar ver

Önce sonucu sınıflandır: geçersiz girdi, eksik yetki, hız sınırı, geçici servis sorunu veya yanıtı bilinmeyen işlem. Yanlış adres biçimini aynı veriyle beş kez göndermek genellikle çözüm üretmez. Hız sınırında ise sağlayıcının önerdiği bekleme ve kapasite koşulları önemlidir. Her hatayı tek bir genel “tekrar dene” koluna bağlamak yerine, operatörün neyi düzeltmesi gerektiğini anlayabileceği durumlar oluştur.

n8n belgeleri hız sınırları için Retry On Fail ve uygun durumlarda Loop Over Items ile Wait gibi seçenekler anlatır. Bu araçların bulunması, bütün dış işlemlerin güvenle tekrarlanabileceği anlamına gelmez. Kullanacağın servisin belgelerini de incele. Özellikle veri değiştiren çağrılarda isteğin etkisini ve sağlayıcının tekrar sözleşmesini birlikte değerlendir. Sadece okuma yapan bir kaynak sorgusuyla ödeme veya mesaj gönderimi aynı riskte değildir.

Deneme bütçesi belirle

Bir iş için en fazla kaç deneme yapılacağını ve toplamda ne kadar süre bekleneceğini yaz. Bekleme süresini yalnızca istek başına değil, bütün işlem yaşamı boyunca düşün. Bir akışın başka bir akış tarafından yeniden başlatılması sınırsız tekrar yaratabilir. İç içe deneme kuralları varsa toplam çağrı sayısını küçük bir örnek üzerinden hesapla. İki katmanda üçer deneme, beklediğinden fazla dış istek üretebilir.

Denemeler bittiğinde işi sessizce atma. İncelenecek bir kayıt oluştur: hangi hedefe gidildi, hangi hata alındı, kaç deneme yapıldı ve son bilinen durum neydi? Bu kayıtta sırlar veya gereksiz kişisel veri bulunmasın. Hata mesajını olduğu gibi günlüğe yazmadan önce içerdiği hassas alanları düşün. Bir kişisel otomasyonda bile anlaşılır bir inceleme kuyruğu, görünmez kayıptan veya sonsuz döngüden daha yararlıdır.

İş kimliğini akış çalıştırmasından ayır

Örnek bir haftalık özet gönderiminde iş, belirli bir haftanın belirli hedefe gönderilecek son metnidir. Aynı gönderim tekrar denendiğinde yeni iş gibi görünmemelidir. Akışın her çalıştırma kimliğini doğrudan iş kimliği olarak kullanmak bu ayrımı bozabilir. İş kaydı oluşturulurken bir kimlik üretip bütün tekrarlarla ilişkilendirmek daha anlaşılır bir modeldir. Gerçek uygulamanın eşzamanlı istekleri de nasıl ele aldığını test et.

Sağlayıcı idempotency desteği sunuyorsa hangi parametreleri aynı kabul ettiğini, anahtarı ne kadar tuttuğunu ve önceki yanıtı nasıl döndürdüğünü kendi belgesinden oku. Stripe’ın idempotent istekleri bu yaklaşımın somut bir örneğini gösterir; ayrıntıları bütün API’ler için genelleme. Destek yoksa kendi gönderim kaydın da tek başına dış servisin işlemi kabul edip etmediğini her ağ kesintisinde kesin bilemeyebilir. Bu sınırı tasarımda görünür tut.

Belirsiz sonuca ayrı bir kapı aç

İstek gönderildikten sonra bağlantı koparsa doğrudan başarısız etiketi koymak yerine sonucun doğrulanamadığını belirtebilirsin. Sağlayıcının işlem sorgulama uç noktası, kayıt kimliği veya yönetim ekranı varsa bağımsız kontrol yap. Henüz gerçekleşmemiş gibi ikinci bir yan etki üretmeden önce bu kanıtı ara. Araştırma mümkün değilse otomatik karar yerine insan incelemesine bırakılacak dar bir yol tanımla. Bu, her akışı elle yürütmek anlamına gelmez.

Son test kümesinde normal başarı, ilk çağrıda geçici hata, kalıcı hata ve yanıtı kaybolmuş kabul edilmiş işlem bulunsun. Her örnekte dış etkilerin sayısını say; yalnızca akışın tamamlandı görünmesine bakma. Buradaki deney alanı gerçek servis çağırmaz ve işlem göndermez. Kendi test ortamında hangi kayıtların oluştuğunu bağımsız okuyarak doğrula. Böylece “yeniden dene” düğmesi bir umut hareketi değil, tanımlı bir toparlanma davranışı olur.

Dış etkiyi sayan bir kabul tablosu kullan

Bir test gönderimini temsil eden tek bir iş kimliği seç. İlk denemede sağlayıcının isteği kabul ettiğini ama yanıtın kaybolduğunu varsay. İkinci denemede sistemin hangi kanıta bakacağını ve hangi durumda duracağını yaz. Tabloda deneme adedi ile gerçek dış etki adedi ayrı sütunlarda olsun. İki deneme yapılmış olması iki mesaj gönderilmesini normal hale getirmez. Aynı şekilde hiç yanıt alınmaması sıfır etki oluştuğunu kanıtlamaz.

Sonraki satırda gerçekten yeni bir iş oluştur. Metni benzer olsa bile hedef veya zaman kapsamı değişmişse bunun yeni kimlikle nasıl temsil edildiğini açıklayabilmelisin. İş tanımı belirsizken yalnızca rastgele anahtar eklemek sorunu çözmez. Son olarak deneme bütçesi dolan kaydı inceleme kuyruğunda bul ve yeniden açma yolunu kontrol et. Kişi yeniden başlat dediğinde yeni bir iş mi oluşuyor, yoksa aynı işin durumu mu araştırılıyor? Bu farkın görünür olması, toparlanmayı hem teknik olarak hem kullanım açısından daha anlaşılır yapar.

Kaynaklar

• n8n: hız sınırlarını yönetme
• n8n: hata iş akışları
• Stripe: idempotent istekler