- Verschifft
- 4. August 2026 um 04:40 UTC
- Autor
- kamo
- Ausschuss
- 519edba
Rückblick auf den ************ Pfad nach dem Entfernen der doppelte Leerlauf-Stack hat vier echte Defekte aufgedeckt: - sessionMonitor.start() ließ seine 3s bootstrap setTimeout untracked, so dass Start/Stopp/Start-Sequenz brachte ein zweites Polling-Intervall hervor, das stoppt() konnte nie klar. Die Timeout-ID wird nun verfolgt und abgesagt. - On orgs mit sessionTimeoutMinutes <= 5 übersteigt der Redis TTL nie die 300er Warnschwelle, so dass der proaktive Zweig nie lief und ACTIVE Den Benutzern wurde bei jedem Check das Timeout-Popup gezeigt. Der Warnpfad jetzt erweitert anstelle von Warnung, wenn der Benutzer innerhalb von 2 Minuten aktiv war. - check() derereferenziert this.config after Wartening; stop() Rennen eine langsame Anfrage warf innerhalb der Pause. Config wird nach jeder Wartezeit erneut überprüft. - clientActivity schrieb localStorage auf jedem Mausschritt (synchrone Schreibvorgänge unter pointer-Frequenz, jedes Brennen Speicherereignis in allen Geschwister-Tabs). Beharrt werden nun auf 5s gedrosselt; der In-Gedächtnis-Zeitstempel bleibt exakt. Auch: handleExtended schließt jetzt immer die Warnung auf Verlängerung - die alte 'TTL - 300' Zustand gestrandet das Popup auf orgs, deren gesamte Auszeit ist <= 5 Minuten. Regressionstests decken den Lebenszyklus und beide Popup-Regeln ab.