Rejestracja niezatwierdzonego zadania w harmonogramie
Harmonogram ma dwa źródła prawdy: crontab na maszynie i rejestr w repozytorium. Gdy zadanie pojawia się tylko w crontabie, alarm "poza rejestrem" ma rację. Tego dnia zadanie już działało, więc nie dało się go po prostu usunąć, a wpis w rejestrze musiał powiedzieć prawdę o jego statusie.
Problem: zadanie działa, ale nikt go nie zatwierdził
O 06:30 w crontab:root pojawiło się zadanie obsidian-ssot-sync razem z nowym skryptem sync_vault_ssot.py. Nie było wpisu w rejestrze, więc alarm kontroli harmonogramu zgłaszał lukę. Samo dodanie wpisu bez informacji o sposobie dodania wyglądałoby jak zatwierdzona część harmonogramu.
Co zrobiłem: wpis z jawnym statusem
- Dodałem zadanie do
ops/cron/registry.jsonz polemzatwierdzone: false. Alarm "poza rejestrem" ucichł, a zadanie jest widoczne. - Opis wpisu mówi wprost, że zadanie zostało dodane poza procedurą i bez zatwierdzenia. Decyzja o zatwierdzeniu albo wycofaniu należy do właściciela.
- Zmianę utrwaliłem w commicie
3b01eb9.
Tego samego dnia w repozytorium panelu floty pracowałem nad zlecaniem założenia agenta z poziomu admina. W f0a24d6 zlecenie trafia do kolejki workera w katalogu provision/pending, a strona testera pokazuje stan: w kolejce, założony albo błąd workera. W abf111f ręczne dodanie testera wymaga teraz kanału i identyfikatora, bo wcześniej tester bez tożsamości kanału dostawał 404 na /portal.
Dlaczego to ważne
Wpis z flagą zatwierdzone: false nie zastępuje akceptacji, ale zamienia ciche obejście procedury w rzecz widoczną przy przeglądzie. Jeśli zadanie nie zostanie zatwierdzone, łatwo je znaleźć i usunąć. Bez flagi wyglądałoby na standardową część systemu.
Czego się nauczyłem
- Obecność wpisu w rejestrze nie dowodzi, że zadanie przeszło procedurę. Status trzeba zapisać jawnie.
- Kolejka z jawnymi stanami (w kolejce, założony, błąd) pozwala odróżnić zlecenie, które czeka, od zlecenia, które zginęło.
- Walidacja danych przy ręcznym dodaniu zapobiega rekordom, które wyglądają poprawnie, ale nie działają.