Aktualizacja n8n v2.x: Jak naprawić zepsute automatyzacje?
Aktualizacja n8n v2.x: Krew, pot i połamane flow
Czy twoje automatyzacje padły po aktualizacji n8n? No moje też. Pisałem już o włamach do n8n i chyba twórcy czytali te same artykuły, bo zrobili mega dużą aktualizację, która zmienia absolutnie wszystko.
Zaczęło się klasycznie. Zauważyłem nowy interfejs, ale całkowicie zignorowałem fakt, że mój automat do bloga przestał działać. Zrobiłem sobie przerwę między wpisami, chciałem zrzucić dane z arkusza i dostałem ścianą błędów w twarz. Pierwszy odruch: wrzuciłem flow do Claude. Efekt? Wygenerowało mi jeszcze więcej krytycznych błędów. Zaktualizowałem instancję na serwerze Mikr.us. Nic. Dopiero Gemini uratowało sytuację.
Aktualizacja n8n do wersji 2.x to nie jest kosmetyczny lifting przycisków. Zrobili tam kompletny remont fundamentów i wycięli stary kod maczetą, żeby platforma przestała pożerać RAM.
Jeśli miałeś stare, rzeźbione na kolanie skrypty – połowa z nich właśnie leży i kwiczy. Dobra wiadomość jest taka, że po tym sprzątaniu system będzie nie do zajechania.
Szybka reanimacja (Notatki z pola walki)
Jak to posprzątać bez rwania włosów z głowy? Oprzyj się na AI.
- Odpal Gemini i napisz wprost, że masz błąd w workflow n8n.
- Zaznacz, że wkleisz całą strukturę flow, z którą model ma się zapoznać.
- W kolejnym kroku wrzuć kod węzła, który wysypał błąd, oraz dokładną treść logu z konsoli.
- Prawdopodobnie to problem z JavaScriptem. Dostaniesz gotowy, poprawny kod do podmiany.
Co poszło pod nóż? (Breaking Changes)
Nowa wersja brutalnie odcina stare mechanizmy. Nie ma tu sentymentów:
- Śmierć MySQL i MariaDB: Twórcy całkowicie wycięli wsparcie. Jeśli hostowałeś n8n na MySQL, system po prostu nie wstanie. Czeka Cię przymusowa migracja do PostgreSQL albo natywnego SQLite.
- Zablokowane zmienne środowiskowe: Wcześniej wciągało się klucze API bezczelnie przez process.env. Nowa architektura odcina węzłom Code bezpośredni dostęp do systemu.
- Izolacja kodu (Task Runners): Każdy kod odpala się w odizolowanym środowisku. To zabija stare skrypty w Pythonie, bo usunięto zmienną _input. Stare tutoriale z YouTube'a możesz wyrzucić do kosza.
- Sub-workflowy działają inaczej: Węzeł Execute Workflow w wersji 1 puszczał proces poboczny, a główny leciał dalej. Teraz główne flow grzecznie czeka na koniec i nadpisuje dane wynikiem z podprocesu.
- Blokada niebezpiecznych węzłów: Chcesz grzebać w plikach systemowych przez Execute Command? Narzędzia są domyślnie wyłączone. Musisz je jawnie odblokować w konfiguracji serwera.
Nowe zasady gry (Dlaczego było warto)
Żeby osłodzić Ci grzebanie w kodzie, wprowadzili mechanizmy zmieniające układ sił.
| Nowy Mechanizm | Co to daje w praktyce? |
|---|---|
| Save vs Publish | Koniec z psuciem produkcji. Kliknięcie "Save" tworzy tylko brudnopis. Możesz psuć i testować do woli, a serwer w tle bezpiecznie realizuje opublikowaną (Publish) wersję. |
| Autosave | Koniec z utratą trzech godzin układania klocków, bo przeglądarka odświeżyła kartę. |
| Turbo SQLite | Baza dostała pooling. Nie korkuje się przy równoległych zadaniach i potrafi działać 10x szybciej. Na tanich VPS-ach to zbawienie dla dysku. |
Jak metodycznie ponaprawiać błędy?
Nie przeklikuj węzłów na ślepo w oczekiwaniu na zielony status. Zrób to jak rzemieślnik:
- Uruchom wbudowany skaner: Wejdź w Ustawienia -> Migration Report. To narzędzie samo przeskanuje Twoją instancję i wypluje dokładną listę węzłów niekompatybilnych z v2.
- Zaktualizuj obsługę plików binarnych: Zamiast przestarzałego bufora binaryData.data, musisz przepisać skrypty JS pod natywne narzędzia: this.helpers.getBinaryDataBuffer().
- Przepnij dane w podprocesach: Odpal próbne testy na głównych flow i przemapuj zmienne w węzłach występujących zaraz po Execute Workflow.
