Problem
When an SSE connection dies ungracefully (network drop, browser crash, tab close), the ConnectionRegistry never removes the stale entry. send_to_user in sse/src/connection.rs logs a warning when sender.send() fails but doesn't unregister the connection. Dead entries accumulate until server restart.
Current behavior
- Client disconnects ungracefully
tx sender remains in the registry
- Every subsequent event triggers:
"Failed to send event to connection..." — but no cleanup happens
- Warnings repeat on every event until server restart
Fix options
Option A: Lazy cleanup in send_to_user
Collect failed connection IDs during iteration, then call unregister for each after the loop completes. Avoids DashMap deadlocks from mutating during iteration. Simple, no new tasks or timers.
Option B: Periodic sweeper task
Background tokio::spawn that periodically iterates connections and removes ones where sender.is_closed() returns true. Doesn't complicate the send path, but adds a background task to manage.
Files
sse/src/connection.rs — send_to_user (line ~101) and broadcast (line ~118) both have this gap
Problem
When an SSE connection dies ungracefully (network drop, browser crash, tab close), the
ConnectionRegistrynever removes the stale entry.send_to_userinsse/src/connection.rslogs a warning whensender.send()fails but doesn't unregister the connection. Dead entries accumulate until server restart.Current behavior
txsender remains in the registry"Failed to send event to connection..."— but no cleanup happensFix options
Option A: Lazy cleanup in
send_to_userCollect failed connection IDs during iteration, then call
unregisterfor each after the loop completes. Avoids DashMap deadlocks from mutating during iteration. Simple, no new tasks or timers.Option B: Periodic sweeper task
Background
tokio::spawnthat periodically iterates connections and removes ones wheresender.is_closed()returns true. Doesn't complicate the send path, but adds a background task to manage.Files
sse/src/connection.rs—send_to_user(line ~101) andbroadcast(line ~118) both have this gap