Source: Audit finding (LOW)
When a Pub/Sub subscriber disconnects abruptly (TCP RST, network partition, kill -9), the `mpsc::UnboundedSender` stored in `PubSubManager` is not removed until the next publish attempt fails. With many short-lived subscribers this leaks senders + their subscribed-channel entries.
Suggested approach:
- On connection drop, `cleanup_pubsub` already removes the client — verify this path runs on *every* disconnect kind (panic in handler, decode error, etc.) by adding integration tests
- Switch from `UnboundedSender` to a bounded `Sender` (e.g. capacity 1024) so a runaway publisher cannot OOM via a stuck subscriber
- Periodic sweep: on each publish, drop sender entries whose channel is closed (`sender.is_closed()` or detect via send-error)
Files: `src/server/mod.rs` (PubSubManager), `src/server/connection.rs` (cleanup_pubsub).
Source: Audit finding (LOW)
When a Pub/Sub subscriber disconnects abruptly (TCP RST, network partition, kill -9), the `mpsc::UnboundedSender` stored in `PubSubManager` is not removed until the next publish attempt fails. With many short-lived subscribers this leaks senders + their subscribed-channel entries.
Suggested approach:
Files: `src/server/mod.rs` (PubSubManager), `src/server/connection.rs` (cleanup_pubsub).