PABLO.ENGINEERING
// WRÓĆ DO WSZYSTKICH WPISÓW
// 3 min

Naprawa archiwów sesji i strażnik serii wychodzących wiadomości

Dzień upłynął mi na łataniu rzeczy, które psuły się po cichu: archiwów, które przestały się otwierać, oraz ewaluacji, które nie mogły się uwierzytelnić do modelu. Obok tego wdrożyłem kilka zabezpieczeń, które mają wyłapywać problemy, zanim zobaczy je użytkownik.

Problem: rzeczy, które gniją bez ostrzeżenia

Archiwa sesji stały się nieczytelne. Dekodowanie zstd działało wcześniej, ale po zmianach przestało odtwarzać dane, więc historia przestawała być dostępna do debugowania i audytu. Równolegle ewaluacje nie mogły połączyć się z modelem, bo konfiguracja profilu auth nie była przenośna. Do tego dzienniki trenera rosły bez żadnego ograniczenia, a serie szybko powtarzanych wychodzących wiadomości mogły dotrzeć do użytkownika jako spam. Osobno pojawiła się flaga podejrzanego wycieku między agentami w pliku pamięci gym, którą oznaczyłem do ręcznego przeglądu.

Co zrobiłem:

  • Przełączyłem dekompresję zstd na odczyt przez stdin i archiwa sesji znów się dekodują (0dd873a).
  • Przebudowałem profile auth dla ewaluacji tak, by były przenośne, żeby ewale znów mogły uwierzytelnić się do modelu (3309930).
  • Dodałem strażnika wykrywającego serie wychodzących wiadomości (10f084e).
  • Dodałem reguły retencji dla dzienników trenera, żeby ograniczyć ich rozrost (6d3a0ad).
  • Przeniosłem parametry analizatora do pliku konfiguracyjnego i dopisałem 50 testów dla tcx_analyzer (84430e1).
  • Oznaczyłem jeden podejrzany przeciek między agentami w pliku pamięci gym i zgłosiłem go do ręcznego przeglądu (leaf-scanner).
  • Wykonałem drobne prace porządkowe: usunąłem zbłąkany plik testowy, który wpadł do commita synchronizacji (df27ab4), oraz zrobiłem trzy rutynowe commity dziennej synchronizacji obejmujące agentów, ewale i pluginy (719e51d, 52d8564, 8b2227f).
  • Zacommitowałem trzy dni dziennych logów pamięci dla czterech agentów (ef1f871, 29.09-01.10).
  • Przeniosłem notatki o incydentach z 2026-09 do osobnego pliku archiwum i poprawiłem wcześniejszy błąd faktograficzny (665cbf1).

Dlaczego to ważne (Use Case):

Odzyskiwalna historia to podstawa debugowania i audytu - jeśli archiwa się nie dekodują, nie mam jak zajrzeć wstecz w zachowanie agentów. Działające ewaluacje wyłapują regresje, zanim zauważy je użytkownik, a bez przenośnego auth po prostu nie dochodzą do modelu. Strażnik serii wiadomości chroni doświadczenie użytkownika przed powiadomieniami spamem, a ograniczona retencja dzienników utrzymuje przewidywalne zużycie miejsca. Flaga podejrzanego przecieku między agentami jest istotna, bo wczesne wychwycenie wycieku prywatnego kontekstu zatrzymuje jego rozprzestrzenianie się między botami.

Czego się nauczyłem:

  • Jednolinijkowa zmiana, jak odczyt zstd przez stdin, potrafi odblokować cały obszar funkcjonalności - warto szukać prostych przyczyn, zanim zacznie się przepisywać pipeline.
  • Bez ograniczeń retencji każdy dziennik rośnie w nieskończoność; ograniczone przechowywanie jest tańsze i bardziej przewidywalne.
  • Testy zamieniają kruchy skrypt w coś, co można bezpiecznie zmieniać - 50 testów dla analizatora daje mi odwagę do dalszych modyfikacji.
  • Ciche awarie, jak serie powtarzanych wysyłek czy nieudane zadania cron, są groźniejsze niż głośne błędy, bo nikt ich nie zauważa, dopóki nie zrobią szkody.
#daily#openclaw#reliability