n8n Planına Göre Execution History Saklama Süresi: 7 Günden Sınırsıza
n8n'in execution history'yi plana göre (Starter'dan Enterprise'a) ne kadar süre sakladığı; hata ayıklama ve muhasebe iş akışlarındaki kayıt tutma yükümlülükleri için önemlidir.
n8n paralel branch'ları neden aynı anda çalıştırmaz ve Merge node'u gerçekte neyi bekler, resmi dokümantasyona göre açıklandı.
n8n'de bir If veya Switch node'undan sonra birden fazla branch'a ayrılan bir workflow oluşturuyorsan, muhtemelen bu branch'ların aynı anda çalıştığını ve Merge node'unda basitçe tekrar buluştuğunu varsayıyorsun. Tam olarak bu varsayım düzenli olarak kafa karışıklığına yol açar, çünkü n8n branch'ları aynı anda anlamında paralel değil, sabit ve izlenebilir bir sırayla çalıştırır. Bu sırayı bilmeyenler, yanlış sırayla gerçekleşiyormuş gibi görünen çalıştırmalara, birbirini geçen API çağrılarına veya sonsuza kadar takılı kalıyormuş gibi görünen bir Merge node'una şaşırır.
İyi haber şu: bunun arkasındaki mantık açıkça belgelenmiştir ve birkaç temel kuralla güvenilir bir şekilde tahmin edilebilir. Bu makalede n8n'in execution order'ı nasıl belirlediğine, versiyon 1.0 ile nelerin değiştiğine ve mantığını bir kez anladığında Merge node'un gerçekte neyi beklediğine bakıyoruz. Böylece her yeni branch ile daha karmaşık hale gelseler bile workflow'ların üzerindeki kontrolü elinde tutarsın.
n8n, resmi Execution Order dokümantasyonuna göre, bir workflow'un ne zaman oluşturulduğuna bağlı olarak temelde birbirinden farklı iki çalıştırma modu arasında ayrım yapar:
Bu fark, çoğu yanlış anlamanın özüdür. Daha eski bir workflow ile çalışan veya eski bir eğitimden bir şablon devralan kişi, güncel bir n8n versiyonunda yeni oluşturulmuş bir workflow inşa eden birinden farklı bir davranış yaşar. Dokümantasyona göre, özellikle diğer davranışa ihtiyacın varsa her iki mod da workflow ayarları üzerinden uyarlanabilir.
Versiyon 1.0 ve sonrası workflow'lar için sabit, izlenebilir bir kural geçerlidir: n8n, node'ların canvas üzerindeki konumuna göre hareket eder. Branch'lar yukarıdan aşağıya işlenir. İki branch aynı yükseklikteyse, yatay konum belirleyicidir ve sol branch önce çalıştırılır.
Bu pratikte şu anlama gelir: workflow'unda bir Switch node'undan sonra iki veya üç paralel branch düzenlersen, hangi branch'ın önce geleceğini yalnızca canvas üzerindeki görsel düzen belirler, bağlantıları çizdiğin sıra ya da herhangi bir dahili ID değil. Bu, tek tek branch'ların yan etkileri olduğunda özellikle önemlidir; örneğin aynı tabloya yazma erişimi, aynı CRM kaydının güncellenmesi veya aynı hız sınırlı API'ye yapılan çağrılar gibi. Bir branch diğerinden önce çalışırsa, ikinci branch'ın sonucu, workflow tasarımında öyle düşünülmemiş olsa bile birinciye bağlı olabilir.
Merge node birden fazla kaynaktan gelen verileri tek bir stream'de birleştirir. Append modunda basit ama sıklıkla gözden kaçan bir kural geçerlidir: node, kendisi devam etmeden önce bağlı tüm girişlerin çalıştırılmasını bekler. Yalnızca her giriş veri sağladığında veya açıkça hiç veri sağlamadığında Merge node bir çıktı verir.
Bu, pratikten iki yaygın gözlemi açıklar:
Merge node'un versiyon 0.194.0'daki büyük yenilenmesinden ve ikiden fazla girişe genişletilmesinin yanı sıra versiyon 1.49.0'daki SQL sorgu modundan bu yana, artık ikiden fazla branch'ı aynı anda birleştirmek de mümkün, bu da klasik iki branch mantığını daha büyük workflow'larda önemli ölçüde basitleştiriyor. Append, Combine ve Choose Branch gibi tüm merge modlarına ilişkin detayları Data Stream'lerini Birleştirme kılavuzunda bulabilirsin.
Dokümantasyona göre özellikle sinsi bir davranış, yalnızca v0 legacy execution order'a sahip workflow'ları, yani varsayılan olarak versiyon 1.0'dan önce oluşturulmuş tüm workflow'ları etkiler. Böyle bir workflow'da bir If node içeren bir yapıya bir Merge node eklersen, If node aslında iki yoldan yalnızca birini tetiklemesi gerekirken, If node'un her iki output stream'inin de çalıştırılması gerçekleşebilir. Nedeni: bir data stream, Merge node'u tetikler ve bu da ardından diğer, aslında aktif olmayan data stream'i de çalıştırır.
Bu davranış versiyon 1.0 ile kaldırıldı. Eski bir workflow'u taşıyan veya bakımını sürdüren ve bir If node'undan sonra açıklanamayan çift çalıştırmalar gözlemleyen kişi, nedenini genellikle burada bulur. Workflow ayarlarında yeni execution order'a geçmek, sorunu genellikle güvenilir bir şekilde çözer.
Mevcut bir workflow'da hata ayıklamadan önce workflow ayarlarına kısa bir göz atmakta fayda var: orada şu anda hangi execution order'ın aktif olduğunu görürsün ve gerekirse v0 ile v1.0 arasında geçiş yapabilirsin. Yeni workflow'lar için genel olarak güncel mantık önerilir, çünkü daha öngörülebilirdir ve açıklanan If artı Merge tuzağı hiç ortaya çıkmaz.
Birden fazla paralel branch ve yan etkiye sahip daha karmaşık otomasyonlarda, canvas düzenini bilinçli olarak kullanmak da faydalıdır: önce çalışması gereken branch'ı üste veya sola yerleştir ve bu niyeti, örneğin bir sticky note aracılığıyla workflow'un içinde kayıt altına al. Böylece takımdaki herkes için sıranın neden tam olarak bu şekilde seçildiği izlenebilir kalır ve kimse bir sonraki yeniden yapılandırmada mantığı yeniden tahmin etmek zorunda kalmaz. Otomasyonların, sıranın artık tek bakışta anlaşılamayacağı kadar dallanmışsa, workflow'ları temiz ve izlenebilir şekilde yapılandırman için sana n8n otomasyonu hizmetimizle destek oluyoruz.
Hayır, en azından aynı anda çalıştırma anlamında değil. Versiyon 1.0 ve sonrası workflow'larda n8n, node'ların canvas üzerindeki konumuyla kontrol edilerek bir branch'ı tamamen işler, ardından bir sonraki başlar. Daha eski v0 workflow'larında ise çalıştırma bunun yerine tüm branch'lar boyunca node node, katman katman ilerler, bu da gerçek bir paralellik değildir.
Append modunda Merge node, bağlı tüm girişlerin çalıştırılmasını bekler. Önceki branch'lardan biri tamamlanmazsa, örneğin bir koşul yerine getirilmediği veya bir node hata verdiği için, Merge node bu girişten hiçbir zaman sinyal almaz ve buna bağlı olarak çıktı üretmez.
Input 1'deki item'lar önceliklidir. Merge node örneğin Input 1'de beş item ve Input 2'de on item alırsa, yalnızca beş item'ı işler, çünkü işleme için üst sınırı Input 1 belirler.
Hayır. n8n dokümantasyonuna göre bu davranış yalnızca v0 legacy execution order'a sahip workflow'lar için, yani varsayılan olarak versiyon 1.0'dan önce oluşturulmuş tüm workflow'lar için geçerlidir. Güncel execution order'a sahip yeni oluşturulmuş workflow'larda bu sorun artık ortaya çıkmaz.
Evet. Execution order, workflow ayarlarında değiştirilebilir. Bu, özellikle If veya Switch node'larından sonra açıklanamayan çoklu çalıştırmalar gözlemliyorsan ve nedenin eski v0 mantığında olduğundan şüpheleniyorsan, eski, taşınmış workflow'lar için faydalıdır.
NordFlux'un kurucusu. Webden ve SEO'dan grup ölçeğindeki otomasyona kadar yedi yıllık deneyim, bugün KOBİ'ler için pragmatik biçimde ve Alman veri egemenliğiyle.
Sertifikalar
n8n'in execution history'yi plana göre (Starter'dan Enterprise'a) ne kadar süre sakladığı; hata ayıklama ve muhasebe iş akışlarındaki kayıt tutma yükümlülükleri için önemlidir.
n8n veritabanının executionlar nedeniyle neden büyüdüğü ve EXECUTIONS_DATA_PRUNE, saklama süresi ile limitlerin veri miktarını nasıl otomatik olarak sınırladığı.
Merge node yanlış sırayı beklediğinde, testte neredeyse hiç görünmeyen ama üretimde ortaya çıkan hatalar oluşur. NordFlux, n8n workflow'larınızdaki execution order ve merge mantığını inceler ve branch'lerin güvenilir şekilde birleşmesi için yeniden yapılandırır. İlk görüşmede kritik workflow'larınızı birlikte gözden geçiririz.