Classic298 263e56e272 fix: keep the session pool reaper alive through a Redis error (#29976) ... A single Redis blip permanently stops orphaned websocket sessions from being reaped. periodic_session_pool_cleanup acquires its lock outside the try, and that try has only a finally, so the first timeout or connection reset ends the coroutine for the life of the process. The session pool then only grows, and the sole trace is one "Task exception was never retrieved" at shutdown. The loop body gets the same try/except Exception its sibling periodic_usage_pool_cleanup already has, which also brings the lock acquire inside the guarded region. The task now logs, releases the lock and retries after the existing delay, so another node can take the lock over meanwhile. The diff reads long because the body is re-indented one level; nothing changes beyond indentation and the four added lines. Only Redis deployments are affected, since the lock functions are lambda: True otherwise. Verified by injecting a ConnectionError at each of the four failure points (acquire, renew, the batch scan, the reaping delete), against a real Redis as well: the task survives all four and keeps retrying, where it previously died on the first. Reaping results, lock acquire and release counts, and cancellation at shutdown are unchanged.		2026-09-13 20:28:10 -05:00
..
main.py	fix: keep the session pool reaper alive through a Redis error (#29976)	2026-09-13 20:28:10 -05:00
utils.py	perf: bounded non-blocking session pool reaper, fewer blocking pool round trips (#28835)	2026-08-31 01:17:53 -04:00