Retry, restart i awaria workera
helpId: poc-jobs
Cel
Sprawdzenie trwałości kolejki SQL i deduplikacji lokalnego efektu przy syntetycznych awariach.
Wymagania i uprawnienia
Lokalne Windows, Node 24, pnpm i własny katalog POC. Używaj wyłącznie testowych danych. Importer wymaga uprawnienia SuperAdmin w kontekście administracyjnym. Testowe dane uwierzytelniające są odrębne od kont użytkownika.
Krok po kroku
- Uruchom pnpm test; harness uruchomi własny proces workera.
- Sprawdź testy pending restart, fail-once oraz fail-always.
- Odczytaj także wynik DEFAULT SQL QUEUE i próbę po hard kill.
- Rozróżnij restart zadania PENDING od przerwania RUNNING. Wynik ręcznej korekty w POC nie jest produkcyjnym lease/fencing.
Przykład
fail-once z retries=2 ma zakończyć się COMPLETED. fail-always z retries=1 ma zakończyć się FAILED po dwóch próbach. Efekt lokalny ma unikalny klucz.
Błędy i rozwiązania
| Błąd | Rozwiązanie |
|---|---|
| LOCAL_POLL_TIMEOUT | Sprawdź lokalny raport. Nie przełączaj połączenia na istniejącą bazę. |
| RUNNING po restarcie | Nie ustawiaj hurtowo zadań na PENDING. W POC korekta dotyczy tylko konkretnego zadania po potwierdzonym zatrzymaniu własnych workerów. |
Anulowanie, korekty i skutki
Nadzorowana korekta w harnessie jest eksperymentem na własnych danych. Produkcja wymaga trwałego dziennika, lease, fencing i reconciliation dla skutków zewnętrznych; lokalna deduplikacja nie zapewnia exactly-once zewnętrznego API.