Stop /api/user-info renewing the TTL for idle users

Fixkamo-internal
Ya
9 Agosti 2026, 19:37 UTC
Mwandishi
kamo
Ahadi ya
32c6c84

This route writes the *** TTL straight to Redis, so it bypassed the gating in SecurityService, MediaService and ChatService entirely — and useUserInfo polls it every 5 minutes forever. On its own it kept every session alive all night after all three services had already stopped renewing for idle users. Caught with redis MONITOR: while the browser truthfully reported 107 minutes idle and SecurityService logged "Skipping sliding expiration", the kamo-internal pod was issuing `expire ***... 1800` against the same key seconds later. Gate it on the same X-Kamo-Idle-Ms signal via a shared helper, so the next route that renews the TTL directly has one obvious thing to call. Absent or malformed header still renews.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei