When a responseTo mismatch is detected, the TCP stream is definitively desynchronized — the driver has read a complete response that belongs to a different request. Currently, the MongoInternalException propagates up as a regular error, but the underlying InternalStreamConnection is not closed. When the connection is returned to the pool, PooledConnection.close() checks wrapped.isClosed() || shouldPrune(wrapped) — and since the stream is not closed and shouldPrune only checks generation, max lifetime, and max idle time, the connection is returned to the available pool for reuse.

This is unsafe because:

The stream state is indeterminate. We cannot know whether the socket buffer still contains orphaned response bytes from other requests. The next operation on this connection may read stale data and produce further mismatch errors or decode garbage.

No existing mechanism discards the connection. Unlike MongoSocketException (which triggers connection close via the read/write error handlers), MongoInternalException from the responseTo check has no special handling — it flows through the same path as application-level command errors.