redis
Wait until next tick before handling socket errors
Description
Per #1593, there is a currently a race condition where an error in a socket.write call can cause the error handler (which clears the command queue) to be fired before the write command is added to the write queue, causing a permanent break in the command queue.
While this situation is rare (it occurs once out of 20 tries to reproduce it) it causes significant pain on downstream consumers, which expects node-redis to return the correct responses. Currently, unless the client implements extra verification that the value returned from node-redis is correct, the client can be working with the completely wrong data in their application.
Description your pull request here
This change adds as little intrusion as possible - wrapping the on_error call in a process.nextTick() to ensure the assumption that the code makes about the socket error handling control flow will always be true. (The code currently assumes that the code inside internalSendCommand will execute to completion before any error handlers are called.)
Checklist
- [x] Does
npm testpass with this change (including linting)? - [ ] Is the new or changed code fully tested?
- [ ] Since this issue is so intermittent, I am not sure how to write an appropriate test. If anyone has advice, I would appreciate it.
- [x] ~~Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?~~ N/A
