Ochrona przed pętlą

Reguła może wywołać zdarzenie, które uruchomi kolejną regułę. To bywa użyteczne — i bywa katastrofą: „zmiana statusu → wyślij e-mail → zmiana statusu” potrafi kręcić się bez końca, zalewając klienta wiadomościami.

Jak to działa

Każde wykonanie ma głębokość w łańcuchu. Reguła uruchomiona przez zdarzenie systemowe ma głębokość 1; reguła uruchomiona przez akcję tamtej — 2; i tak dalej.

Po przekroczeniu 10 poziomów łańcuch jest przerywany. Wykonanie dostaje status „wykryto pętlę” i widoczny komunikat z osiągniętą głębokością. Nic więcej się nie wykonuje.

Czego ta ochrona nie robi

Nie wykrywa pętli przed uruchomieniem — jest bezpiecznikiem, nie analizą. Dziesięć poziomów zdąży się wykonać, zanim licznik zadziała. Jeśli w tym łańcuchu jest wysyłka e-maila, klient dostanie do dziesięciu wiadomości.

Zanim włączysz regułę, która zmienia to, co ją wyzwala

Regułę wyzwalaną zmianą statusu, która sama zmienia status, zawęź warunkiem na status docelowy — wtedy drugi obieg nie spełni warunku i zatrzyma się sam, bez czekania na bezpiecznik.

Przerwa nie zeruje licznika

Akcja „Czekaj” wstrzymuje regułę, ale wznowienie odtwarza głębokość łańcucha zamiast liczyć ją od nowa. Bez tego para reguł wołających się nawzajem przez przerwę omijałaby bezpiecznik w nieskończoność.

Sprawdzanie reguły

POST /api/automations/loop-check analizuje zestaw reguł i wskazuje te, które mogą się wywoływać wzajemnie — zanim je włączysz.