Files
bitchat/bitchat
jack 8fccbe69b9 Fix session destruction race condition causing handshake delays
Root cause: When receiving a handshake initiation (32 bytes) from a peer
with whom we already had an established session, the code would destroy
the existing session to "help" the other side. This created a cascade:
- Peer A completes handshake with Peer B
- Peer A sends message, realizes no session, initiates handshake
- Peer B destroys its working session to "help"
- Peer B now has no session, initiates handshake
- Both peers keep destroying each other's sessions

Fix:
- Never destroy an established session when receiving new handshake attempts
- Add early check in handshake initiation to skip if session exists
- Clear handshake rate limit timers when session already established

This eliminates the delays and repeated handshakes seen in the logs.
2025-07-22 11:06:57 +02:00
..