Problem
Two robustness issues in clawhive-channels/src/wecom.rs:
1. WebSocket write contention
Line 245 — Arc<Mutex<WsSink>> risks lock contention under load. Multiple tasks contending for the write lock can cause latency spikes or deadlocks.
Proposed fix: Replace with bounded MPSC channel + dedicated writer task pattern. Messages are sent to the channel, and a single task handles all WebSocket writes sequentially.
2. Message dedup memory management
Line 270 — Message dedup uses HashSet that clears entirely at 10k entries. This means:
- Brief window of no dedup protection after clearing
- Memory usage is unpredictable (0 to 10k entries)
Proposed fix: Use LRU cache or time-based expiry (e.g., expire entries after 5 minutes) for smoother memory usage and continuous dedup protection.
Impact
- Stability — prevents lock contention under high message volume
- Correctness — maintains continuous dedup protection without gaps
Problem
Two robustness issues in
clawhive-channels/src/wecom.rs:1. WebSocket write contention
Line 245 —
Arc<Mutex<WsSink>>risks lock contention under load. Multiple tasks contending for the write lock can cause latency spikes or deadlocks.Proposed fix: Replace with bounded MPSC channel + dedicated writer task pattern. Messages are sent to the channel, and a single task handles all WebSocket writes sequentially.
2. Message dedup memory management
Line 270 — Message dedup uses
HashSetthat clears entirely at 10k entries. This means:Proposed fix: Use LRU cache or time-based expiry (e.g., expire entries after 5 minutes) for smoother memory usage and continuous dedup protection.
Impact