We've been seeing clients hang in rare cases when a connection drops, in the sense that request promises are not fulfilled leaving our code hanging. The cases fixed here are hard to pinpoint because there's no logging to help, I managed to produce these cases here semi-reliably and debug them.
So there seems to be a gap in when we have the error timeouts set, and that gap is basically between incoming IMAP commands.
So I've added a couple of timeout resets to _handleResponse for when all these conditions are met:
A command is finished (and the socket timeout cleared in _iterateIncomingBuffer).
_currentCommand still exists.
a response to _currentCommand is not yet ready for a callback.
This seems to have fixed the client hangs I was able to produce - the result is that in those cases the timeout would fire and the client would error out, rejecting the request promise.
We've been seeing clients hang in rare cases when a connection drops, in the sense that request promises are not fulfilled leaving our code hanging. The cases fixed here are hard to pinpoint because there's no logging to help, I managed to produce these cases here semi-reliably and debug them.
So there seems to be a gap in when we have the error timeouts set, and that gap is basically between incoming IMAP commands.
So I've added a couple of timeout resets to _handleResponse for when all these conditions are met:
This seems to have fixed the client hangs I was able to produce - the result is that in those cases the timeout would fire and the client would error out, rejecting the request promise.