Trująca wiadomość w automatyzacji (poison message)

Trująca wiadomość, po angielsku poison message albo poison pill, to zdarzenie w kolejce lub workflow, którego konsument nie jest w stanie przetworzyć poprawnie, ale system stale próbuje je obsłużyć. Przyczyną bywa zły format danych, brak wymaganej informacji, zmiana API, nieaktualne uprawnienie albo błąd w logice automatyzacji. To nie jest synonim awarii całego systemu. Jedna wadliwa sprawa może jednak zużywać kolejne próby, zatrzymać przetwarzanie następnych zadań i ukryć prawdziwy problem pod rosnącą liczbą błędów.

W systemie AI taki komunikat może wyglądać zwyczajnie: formularz bez identyfikatora klienta, plik bez tekstu do ekstrakcji, rekord CRM z niespodziewanym polem albo webhook z podpisem, którego nie da się zweryfikować. Agent może poprawnie wygenerować odpowiedź, lecz potem nie zapisać jej w CRM, bo docelowe pole ma inny typ. Jeśli automatyzacja przy każdym podejściu pobiera dane, wywołuje model i wraca do tego samego błędu zapisu, płacisz za kolejne przebiegi bez rezultatu dla klienta. Dlatego analizuj cały łańcuch, nie tylko krok z modelem.

Najważniejsze jest odróżnienie błędu trwałego od chwilowego. Timeout, odpowiedź 429 lub krótka niedostępność dostawcy mogą uzasadniać ograniczone ponowienie. Brak pola, nieprawidłowy JSON albo odrzucona walidacja zwykle nie naprawią się po trzeciej identycznej próbie. AWS opisuje poison pill jako wiadomość odebraną, której nie można przetworzyć, i zaleca użycie kolejki błędów, aby nie zniekształcała metryk oraz nie wracała bez końca do głównej kolejki. Polityka retry powinna więc wskazywać typy błędów, maksymalną liczbę prób i moment przekazania sprawy dalej.

Praktyczny przykład: po zakupie produktu workflow pobiera dane zamówienia, tworzy podsumowanie AI i zakłada kontakt w CRM. Jeden stary formularz wysyła numer telefonu jako obiekt zamiast tekstu. Zapis do CRM kończy się błędem walidacji, a automatyzacja próbuje ponownie co pięć minut. Właściwa reakcja to zatrzymać ponawianie dla tego typu błędu, dołączyć identyfikator zamówienia, treść błędu i numer kroku, a potem przenieść sprawę do kolejki błędów lub listy ręcznej obsługi. Po poprawie mapowania danych można wznowić wyłącznie tę konkretną sprawę.

Kolejka błędów, czyli DLQ, nie jest koszem na śmieci. Jest miejscem diagnostycznym dla zadań, które przekroczyły bezpieczny limit prób lub wymagają decyzji człowieka. Microsoft wskazuje, że wiadomości w DLQ należy obejrzeć, usunąć po świadomej decyzji albo poprawić i wysłać ponownie. Samo przeniesienie sprawy do DLQ nie naprawia źródła problemu. Jeśli w każdą środę trafia tam ten sam typ webhooka, potrzebujesz poprawki kontraktu danych, a nie większego limitu retries.

Do każdej wiadomości dodaj stabilny identyfikator zdarzenia, źródło, wersję schematu, czas pierwszej próby, liczbę dostarczeń i końcowy powód odrzucenia. Bez tych danych nie odróżnisz jednego wadliwego rekordu od regresji po zmianie integracji. Nie kopiuj jednak całych danych klienta do alertu lub logu tylko dlatego, że ułatwia to debugowanie. Zapisuj minimalny kontekst potrzebny do odtworzenia sprawy i kontroluj, kto ma do niego dostęp. To szczególnie ważne, gdy workflow zawiera briefy, transkrypcje lub dane płatności.

Nie wznawiaj automatycznie wszystkich wiadomości z DLQ po wdrożeniu poprawki. Najpierw wybierz małą próbę, sprawdź wynik na danych testowych i upewnij się, że operacja jest idempotentna. Timeout po stronie automatyzacji nie oznacza, że CRM, e-mail lub płatność nie wykonały już akcji. Klucz idempotencji albo sprawdzenie istniejącego stanu chroni przed podwójną wiadomością i podwójnym rekordem. Dopiero po tej kontroli możesz stopniowo ponowić poprawione sprawy.

Dla solopreneurki rozsądny start jest prosty: przy krytycznym workflow spisz trzy najczęstsze błędy, ustaw osobne zachowanie dla przejściowych i trwałych, dodaj alert o pierwszej wiadomości w DLQ oraz wyznacz właściciela przeglądu. Monitoruj liczbę spraw w kolejce, ich wiek i powtarzający się powód odrzucenia. Trująca wiadomość jest sygnałem o granicy procesu. Dobrze obsłużona nie znika po cichu, lecz daje konkretne dane, dzięki którym system AI odzyskuje sprawę bez mnożenia kosztów i bez psucia doświadczenia klienta.