n8n 2.45: durable scheduler domyślnie chroni harmonogramy po restarcie

W wersji n8n 2.45 domyślnie włączył się tzw. durable scheduler dla węzłów Schedule Trigger. Brzmi technicznie, ale dla każdego, kto automatyzuje raporty, przypomnienia czy synchronizację danych, to jedna z ważniejszych zmian w ostatnich miesiącach – mniej „zgubionych” cronów po restarcie serwera.

Co się zmieniło

Wcześniej wiele harmonogramów w n8n trzymanych było głównie w pamięci procesu. Restart serwera, aktualizacja kontenera albo krótka przerwa w działaniu mogły sprawić, że zaplanowane uruchomienie po prostu nie wystartowało. Nowy scheduler zapisuje każde zaplanowane uruchomienie w bazie danych jeszcze przed terminem. Po restarcie n8n wie, co miało się wykonać, i w okresie łaski (grace period) nadal odpala zaległe zadanie.

W instalacji z wieloma węzłami głównymi (multi-main) jedno uruchomienie przejmuje jeden main – nie ma już sytuacji, w której wszystkie liderzy strzelają jednocześnie tym samym jobem. Zmiana obejmuje nowe i istniejące węzły Schedule Trigger: po aktualizacji nie trzeba ich publikować od nowa. Poll triggery i zadania systemowe zostają na dotychczasowych mechanizmach.

Na co uważać przy migracji

Harmonogramy „co N sekund / minut” liczą teraz odstęp od momentu publikacji workflow, a nie od pełnych godzin zegara. Jeśli miałeś job o :00, :15, :30, :45 i polegałeś na wyrównaniu do zegara, po upgrade’ie czasy mogą się lekko przesunąć. Godzinowe, dzienne, tygodniowe i klasyczne crony w codziennym użyciu zachowują się jak wcześniej – różnice widać głównie w rzadkich przypadkach (rok przestępny, 53. tydzień, zmiana czasu).

Na okres przejściowy n8n zostawił zmienne środowiskowe N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy (stare wyrównanie do zegara na nowym schedulerze) oraz N8N_SCHEDULER_ENABLED=false (powrót do schedulera w pamięci). Obie są oznaczone jako deprecated – w przyszłych wersjach znikną razem ze starym mechanizmem. Warto więc przetestować krytyczne workflow na stagingu przed wyłączeniem tych „protez”.

Dla kogo to ważne

Jeśli trzymasz n8n na VPS-ie, w Dockerze albo Kubernetes i restartujesz instancję przy deployach, durable scheduler zmniejsza ryzyko pominiętych zadań. Przy automatyzacjach księgowych, codziennych raportach do Slacka/Maila czy integracjach z ERP to konkretna poprawa niezawodności. Przed upgrade’em produkcyjnym sprawdź aktualny changelog n8n: linia 2.45 wchodziła najpierw jako beta, a wersja stable bywa o jeden patch w tyle.

Źródło: n8n Docs – Changelog (durable scheduler w 2.45)

Artykuł zredagowany przy pomocy AI.