W pętli awaria narzędzia zatrzymuje przebieg. W grafie zatrzymuje też wszystkich, którzy na ten węzeł czekali — a najgorszy wariant to ten, w którym nikt się o tym nie dowiaduje.
Awaria w pętli jest prosta w tym jednym sensie, że jest widoczna. Narzędzie rzuca wyjątek, pętla musi zdecydować, co z tym zrobić, a jeśli nie zdecyduje, przebieg się kończy i ktoś to zauważy.
W grafie awaria ma inną własność: węzeł ma następników. Coś, co czekało na jego wynik, nie dostanie go — i to, co się wtedy stanie, zależy od decyzji, których większość ludzi nie podejmuje świadomie, tylko odziedzicza po domyślnych ustawieniach narzędzia.
Cztery rodzaje awarii, cztery różne reakcje
Rozróżnienie ma znaczenie, bo reakcja odpowiednia dla jednego rodzaju jest zła dla pozostałych.
Węzeł się wywalił. Wyjątek, timeout, padł proces. Najłatwiejszy przypadek, bo jest jawny. Wiadomo, że coś się stało, i wiadomo gdzie.
Węzeł skończył, ale nie zrobił zadania. Zwrócił wynik, który przeszedł przez wszystkie mechanizmy, a merytorycznie jest pusty albo błędny. To jest odpowiednik syndromu, który u ciebie w Patologii nazywa się „agent kończy, ale zadania nie wykonał” — z tą różnicą, że w grafie ten wynik jedzie dalej i staje się wejściem dla następnika.
Węzeł nie skończył i nie skończy. Utknął w swojej wewnętrznej pętli, czeka na coś, co nie przyjdzie, albo został zabity bez zapisania stanu. Nie ma wyjątku, więc nie ma sygnału.
Węzeł nigdy nie wystartował. Router nie wybrał żadnej krawędzi, złączenie czeka na wejście, którego nikt nie wyprodukował, zadanie zostało zajęte przez wykonawcę, który padł. Najtrudniejszy do wykrycia, bo w logu nie ma nic — dosłownie nie wydarzyło się zdarzenie, którego szukasz.
Ostatni rodzaj jest specyficzny dla grafu. W pętli nie istnieje, bo pętla albo się kręci, albo się skończyła.
Zakleszczenie: cicha awaria grafu
Najgorszy scenariusz nie polega na tym, że coś się wywala. Polega na tym, że graf stoi i wygląda, jakby pracował.
Złączenie czeka na trzy wejścia, dostało dwa. Trzeci węzeł został zajęty przez wykonawcę, który przestał istnieć — zadanie ma status „w toku” i nikt go nie zwolni. Reszta grafu czeka. Żaden monitoring oparty na błędach niczego nie zgłosi, bo błędu nie było.
Trzy mechanizmy, które to rozbrajają, i wszystkie trzeba świadomie włączyć:
Dzierżawa zamiast zajęcia. Wykonawca nie zajmuje zadania na zawsze, tylko na czas — i musi tę dzierżawę odnawiać. Jeśli przestanie, zadanie wraca do kolejki. To jest standardowy mechanizm z systemów kolejkowych i jedyna rzecz, która ratuje przed zadaniami zajętymi przez nieistniejących wykonawców.
Termin na węźle, nie tylko na całości. Limit czasu dla całego zadania nie wystarcza, bo mówi tylko, że coś trwa za długo, i nie mówi gdzie. Osobny termin na węzeł wskazuje miejsce.
Zdarzenie zamiast braku zdarzenia. Monitoring, który patrzy na błędy, nie zobaczy zakleszczenia. Monitoring, który sprawdza, czy zadanie w toku ruszyło się w ostatnich N minutach — zobaczy.
Co zrobić z następnikami
Cztery strategie. Wybór zależy od tego, czy wynik węzła był konieczny, czy tylko przydatny.
Zatrzymać graf. Cała praca staje, zadanie idzie do przeglądu. Właściwe, gdy wynik był konieczny i nie ma sensownego zastępnika. Kosztuje czekanie, ale nie produkuje śmieci.
Iść dalej z brakiem. Następnik dostaje informację, że tego elementu nie ma, i sam decyduje, czy da się bez niego pracować. Wymaga, żeby brak był przekazany jawnie — a nie jako pusta wartość, którą model uzna za odpowiedź.
Objazd. Krawędź awaryjna do węzła zastępczego: prostszego, tańszego, na innym dostawcy. Dobre przy węzłach zależnych od zewnętrznych usług.
Ponowić. Najczęstsza domyślna reakcja i najbardziej ryzykowna w grafie. Powtórzenie węzła po awarii jest bezpieczne tylko wtedy, gdy węzeł nic nie zmienił w świecie zewnętrznym. Jeśli zdążył wysłać, zapisać albo obciążyć — ponowienie robi to drugi raz.
Zasada, która porządkuje wybór: ponawiaj węzły, które tylko czytają. Węzły, które piszą, ponawiaj wyłącznie wtedy, gdy zapis jest idempotentny — czyli gdy wykonanie go dwa razy daje ten sam skutek co jeden.
Brak musi być wartością
To jest rzecz, która wygląda na drobiazg implementacyjny, a jest jedną z częstszych przyczyn cichych błędów w grafach.
Jeśli węzeł zawiódł, a następnik dostaje w stanie puste pole, model potraktuje to jako informację: nic nie znaleziono. Wynik będzie wyglądał poprawnie i będzie nieprawdziwy — bo różnica między „sprawdziliśmy i nie ma” a „nie udało się sprawdzić” jest fundamentalna, a w pustym polu nie widać żadnej z nich.
Awaria musi być zapisana jako stan, nie jako brak stanu. Pole z informacją, że węzeł nie dostarczył wyniku, wraz z powodem. Wtedy następnik ma na czym oprzeć decyzję, a ty masz co znaleźć w logu.
To jest ta sama zasada, która w pętli dotyczy wyniku zawodzącego narzędzia — tylko konsekwencje są większe, bo w grafie ten pusty stan jedzie dalej i mnoży się przez następników.
Jak to sprawdzić u siebie
Test, który nie wymaga czekania na awarię: wyłącz jeden węzeł celowo i zobacz, co się stanie.
Weź graf, który już działa, i zrób trzy przebiegi:
Węzeł rzuca wyjątek. Czy graf się zatrzymał, czy poszedł dalej? Czy dowiedziałeś się o tym, czy zauważyłeś przypadkiem?
Węzeł zwraca pusty wynik bez błędu. Co dostał następnik i jak się zachował? Czy w wyniku końcowym widać, że czegoś brakowało?
Węzeł nie odpowiada w ogóle — zasymuluj to opóźnieniem dłuższym niż jakikolwiek limit. Czy cokolwiek zgłosiło, że zadanie stoi? Po jakim czasie?
Trzeci przebieg jest zwykle najbardziej pouczający, bo w większości grafów zbudowanych bez świadomej decyzji odpowiedź brzmi: nic nie zgłosiło i stoi do dziś.
Co dalej
Wiadomo już, co robić, gdy węzeł zawiedzie. Zostaje pytanie, którego ten artykuł dotknął tylko przy ponowieniach: co węzłowi wolno zrobić, zanim zawiedzie.
Bo część awarii nie polega na tym, że coś się nie udało — tylko na tym, że udało się coś, czego udać się nie powinno.
O tym jest artykuł siódmy: Granice, których nie egzekwuje agent.
Stan na sierpień 2026. Mechanizmy opisane wyżej — dzierżawa zadania, terminy per węzeł, idempotentność zapisu — pochodzą z systemów rozproszonych i kolejkowych. W narzędziach agentowych bywają dostępne, ale rzadko domyślnie włączone.
