Bir iş akışı, uzak bir sistemde bir kayıt oluşturur, ardından yanıt beklerken zaman aşımına uğrar. Yürütme, başarısız olarak işaretlenir. Bir operatör “tekrar dene” düğmesine basar ve uzak sistem aynı oluşturma isteğini yeniden alır.
Bu akıştaki hiçbir adım, olağandışı bir kesintiye yol açmaz. Bu, bir ağ üzerinden işlerin yürütülmesinin normal bir sonucudur. n8n otomasyonlarını tasarlarken, tekrar oynatma davranışını iş akışının iş mantığının bir parçası olarak ele alırım.
İşleme istikrarlı bir kimlik verin
Bir yürütme tanımlayıcısı, hangi denemenin gerçekleştirildiğini gösterir. Ancak bu, iş işlemini mutlaka tanımlamaz. İş akışı yeniden başlarsa, yeni yürütme yine de aynı siparişi dışa aktarmaya çalışıyor olabilir.
Kiracı, kaynak kayıt, eylem ve ilgili sürümden oluşan bir işlem anahtarı tercih ederim. Örneğin, bir siparişin belirli bir revizyonunun dışa aktarılması, yeniden denemeler boyunca aynı anahtara sahip olmalı; buna karşın, daha sonraki bir revizyonun dışa aktarılması ise farklı bir anahtara sahip olmalıdır.
Anahtar, eşzamanlılık koşullarında benzersizliği sağlayabilen bir sistemde depolanmalıdır. Bir değerin mevcut olup olmadığını kontrol etmek ve ardından onu ayrı adımlarda eklemek, iki işçi aynı anda çalışmaya başladığında bir yarış durumu yaratır.
Yan etkilerin sınırlarını belirleyin
Saf dönüşümler genellikle kolayca tekrarlanabilir. Mesaj göndermek, fatura oluşturmak veya stok bilgilerini değiştirmek gibi işlemler için daha dikkatli bir sınır belirlenmesi gerekir.
Tercih ettiğim sıralama şudur: Hedeflenen işlemi kaydetmek, bu işlemi atomik olarak talep etmek, destekleniyorsa bir idempotans anahtarı kullanarak harici hizmeti çağırmak ve sağlayıcının referansını kaydetmek. Zaman aşımı, uzlaştırma gerektiren belirsiz bir işlem bırakır; bu durum otomatik olarak bir başarısızlık kanıtı olarak değerlendirilmemelidir.
Hizmet sağlayıcı idempotans özelliğini desteklemiyorsa, harici bir referans kullanarak sorgulama yapmanın güvenilir bir yolunu ararım. Her iki seçenek de mevcut değilse, iş akışında bir inceleme kuyruğuna ihtiyaç duyulabilir. İkinci bir körü körüne deneme, özellikle de eylem kolayca geri alınamıyorsa, bir iş kararıdır.
Giderilemeyen hataları, düzeltilebilir verilerden ayırın
Geçici bir bağlantı hatası daha sonra düzeltilebilir. Eksik bir müşteri kimlik numarası ise genellikle düzeltilemez. Süresi dolmuş bir kimlik bilgisi için bir operatörün müdahalesi gerekebilir; hız sınırlaması durumunda ise bir bekleme süresi ve daha düşük eşzamanlılık gerekebilir.
| Başarısızlık | İş akışı yanıtı |
|---|---|
| Geçici hizmet hatası | Artan gecikme ve dalgalanma ile sınırlı yeniden deneme |
| Geçersiz kaynak kaydı | Okunabilir bir doğrulama gerekçesiyle karantina |
| Belirsiz harici yazma | İşlem referansını kullanarak mutabakatı gerçekleştirin |
| Eksik izin | Etkilenen işlemi durdurun ve yapılandırma onarımı isteyin |
Yeniden deneme politikası için toplam bir zaman bütçesi de gereklidir. Günlerce yeniden deneme yapan bir otomasyon, iş bağlamı değişmiş olduktan sonra bir eylemi uygulayabilir. Eski işler için bir son geçerlilik tarihi veya yeni bir uygunluk kontrolü bulunmalıdır.
Devam edebilmek için yeterli durumu koruyun
Önemli iş sınırlarında kalıcı kontrol noktaları tutarım. Bir dışa aktarma işlemi başarılı olmuş ancak bildirim başarısız olmuşsa, kurtarma işlemi bildirimi hedef almalıdır. İş akışının tamamını tetikleyicisinden itibaren yeniden çalıştırmak, yalnızca önceki her eylemin tekrarlanmasının güvenli olduğu durumlarda uygun olur.
Her kontrol noktası, bekleyen, devam eden, tamamlanmış, başarısız ve durumu belirsiz işleri birbirinden ayırt etmelidir. Devam eden bir işlem için ayrıca, çöken bir işçinin bu işlemi sonsuza kadar elinde tutmaması amacıyla bir kiralama veya kurtarma kuralı gereklidir.
Günlük kayıtları, işlem anahtarını, deneme numarasını, harici referansı ve iş akışı sürümünü içermelidir. Kontrol edilen bir referans soruşturmayı destekleyebiliyorsa, her hata mesajına tam müşteri yüklerini eklemekten kaçınırım.
Uygunsuz zamanlamayı test edin
Bir otomasyona güvenmeden önce, ana dış eyleminin hemen öncesinde ve hemen sonrasında bir arıza simülasyonu yaparım. Ayrıca aynı girdiyi iki kez çalıştırır ve iki denemeyi aynı anda başlatırım.
Bu kontroller, sadece bir başka başarılı denemeden daha fazlasını ortaya koymaktadır. Yararlı bir iş akışı, halihazırda nelerin yapıldığını, nelerin hâlâ belirsiz olduğunu ve operatörün hangi eylemi güvenli bir şekilde tekrarlayabileceğini açıklayabilir.
25 Eylül 2026 tarihinde güncellenmiştir.