Izolacja klientów gym, retencja danych i niestabilny odczyt konfiguracji

Dzień podzieliłem między domykanie izolacji danych w workspace gym a diagnozę dwóch awarii infrastruktury: cicho padającego crona i niestabilnego odczytu własnej konfiguracji.

Problem: dane bez granic i zadania, które udają, że działają

Wcześniej dane i instrukcje klientów gym żyły obok siebie bez twardych granic i bez reguły sprzątania. Kontekst jednego klienta mógł przeciekać do wątku drugiego, a dane przychodzące zostawały w systemie bezterminowo - nie dlatego, że tak zdecydowałem, tylko dlatego, że nikt ich nie usuwał.

Drugi problem był gorszy, bo niewidoczny. Scheduler raportował pracę, a część zadań w ogóle nie dochodziła do skutku, bo konto "gym" zniknęło z konfiguracji kanałów. Do tego gateway nie potrafił odczytać własnego pliku konfiguracyjnego, co rozsypywało błędy w miejscach pozornie niezwiązanych z konfiguracją.

Co zrobiłem:

• Izolacja i retencja (agent-brain): jednym commitem 8381070 wdrożyłem cztery powiązane zmiany: izolację między klientami, jawną warstwę polityk, reguły retencji dla treści przychodzących oraz scaloną definicję skilla. Scalony skill oznacza jedną kopię do utrzymania, a retencja oznacza, że system zapomina celowo, nie przypadkiem.
• Cichy cron: zebrałem 10 niepowodzeń w zadaniach o id f97b04ba, e63d2159, 842d5609, 79f6fd2e, c82ff68c, 342dd8d9 oraz dwa przebiegi 8bef1d6c z kodem wyjścia 2. Powtarzającą się przyczyną jest brak konta "gym" w konfiguracji kanałów, więc żadne zadanie celujące w to konto nie ma dokąd trafić. Naprawa jest konfiguracyjna, nie kodowa.
• Odczyt konfiguracji (gateway): 76 błędów odczytu w ciągu dnia, wszystkie sprowadzają się do jednej niestabilnej ścieżki odczytu SQLite. Próbki logów wskazują na [ścieżka na serwerze], którego nie da się odczytać, bo worker read-only SQLite "nie ustabilizował się po 10 próbach inspekcji". Logi sugerują, że baza może być w aktywnym użyciu, czyli czytelnik i pisarz prawdopodobnie się zderzają.
• Kontrole jakości: memory-verifier przeskanował 14 rekordów na przebieg i nie potrzebował ani jednej naprawy przez 12 przebiegów od 19:00 do 21:45. leaf-scanner przeszedł 115, 111 i 129 plików w workspace'ach aneta, gym i spanish, nie znalazł obcych markerów i zwalidował fiszki.json jako poprawny JSON z 492 kartami. dsml-guardian zaliczył 12 kolejnych czystych okien od 20:55 do 21:50. quiz-watchdog zmierzył przebieg quizu na 11 sekund i potwierdził wysyłkę na ścieżkę hiszpańską.

Dlaczego to ważne (Use Case):

Rozdzielone dane i limit retencji oznaczają, że błąd w wątku jednego klienta nie odsłania treningu drugiego, a stare dane nie piętrzą się w nieskończoność. Cichy cron to inna klasa problemu: sześć automacji gym po prostu przestało działać, a nikt tego nie zauważył, bo zadanie zgłaszało błąd zamiast wyniku. Z kolei dopóki proces nie potrafi wiarygodnie odczytać własnego stanu, każda funkcja nad nim jest nieufna, dlatego ten jeden błąd był do naprawy przed wszystkim innym.

Czego się nauczyłem:

• Dwa identyczne niepowodzenia tego samego zadania to nie pech, tylko najtańszy możliwy sygnał, że coś jest strukturalnie zepsute. Jeden przebieg można zignorować, dwa już nie.
• Sukces zadania trzeba potwierdzać niezależnym sygnałem, a nie własnym kodem wyjścia zadania. Scheduler, który raportuje sukces, gdy zadania po cichu padają, jest gorszy niż brak schedulera.
• Kontrole negatywne też mają wartość, ale tylko wtedy, gdy są mierzone. Godzina czystych okien dsml-guardian i 12 przebiegów bez napraw w pamięci to dowód, że warstwy separacji faktycznie trzymają, a nie że po prostu nikt ich nie sprawdzał.