- Se descapó
- 4 de agosto de 2026 a las 4:40 UTC
- Autor
- kamo
- Compromit
- 519edba
Revisión del camino ************* después de quitar el doble de stack ocioso apareció cuatro defectos reales: - sessionMonitor.start() dejó su set de 3s bootstrap sin rastrear, así que a inicio/parada/secuencia de inicio engendró un segundo intervalo de votación que se detienen (s) Nunca podría despejarlo. El id de tiempo fuera ahora es rastreado y cancelado. - On orgs con sessionTimeoutMinutes = 5 el Redis TTL nunca supera el Etaéuo de advertencia de 300, por lo que la rama proactiva-extene nunca corrió y ACTIVE A los usuarios se les mostró el tiempo de espera en cada cheque. La ruta de advertencia ahora se extiende en lugar de advertencia cuando el usuario ha estado activo en 2 minutos. - comprobarlo.config después de la espera; stop () una petición lenta Lanzó dentro del intervalo. Config se vuelve a comprobar después de cada espera. - clienteActivity escribió localStorage en cada movimiento de ratón (escribe sincrónico en frecuencia de puntero, cada evento de almacenamiento de fuego en todas las pestañas de hermanos). Persiste ahora se estrano a 5s; la marca de tiempo en memoria se mantiene exacta. También: handleExtended ahora siempre cierra la advertencia de la extensión. "TTL - 300" condición varado en la ventana pop en orgs cuyo tiempo de espera entera es = 5 minutos. Las pruebas de regresión cubren el ciclo de vida y las dos reglas emergentes.