Race condition: concurrent sendAndRecv() during reconnect can corrupt protocol state

[yeongseon]

Context

Identified during review of PR #16 (CAS reconnect on inactive broker). The checkReconnect() method added by that PR is guarded by a mutex, but the broader sendAndRecv() call path is not fully serialized against the reconnect flow.

Problem

When multiple async operations call sendAndRecv() concurrently and one triggers a reconnect:

1. Operation A detects socket death, enters checkReconnect()
2. Operation B is mid-flight in sendAndRecv() writing to the old socket
3. checkReconnect() replaces the socket while B is still writing
4. B's data goes to the new (reset) socket → protocol state corruption

Additionally

The socket error handler silently swallows errors:

socket.on('error', () => {}); // silent — should log

This masks real connection problems. Replace with proper logging.

Proposed Fix

1. Serialize sendAndRecv against reconnect: acquire the same mutex (or a dedicated connection mutex) around the full sendAndRecv() lifecycle, not just around checkReconnect().
2. Add error logging: replace silent socket error handler with this.logger?.error(...) or equivalent.

References

• Introduced/merged in PR fix: reconnect when CAS released under KEEP_CONNECTION=AUTO #16
• Review comment: fix: reconnect when CAS released under KEEP_CONNECTION=AUTO #16