redis
With commandTimeout option set, active timers are not cleared on client disconnection
With the commandTimeout option set, a timer is set up here: https://github.com/luin/ioredis/blob/eabb70ed835828ad85b602a217992486e05d2218/lib/Command.ts#L292-L300
the only place this timer gets cleared is here:
https://github.com/luin/ioredis/blob/eabb70ed835828ad85b602a217992486e05d2218/lib/Command.ts#L349-L366
and that only gets called on successful resolution of the command...
https://github.com/luin/ioredis/blob/eabb70ed835828ad85b602a217992486e05d2218/lib/Command.ts#L302-L324
The result is that if the client is disconnected while there is an active command timeout, there ends up being an orphaned timer in the nodejs process. In my case, this is causing tests and lambda executions to hang until the timer clears.
Possible simple fix is just to clear the timer on promise rejection too, here? I'm not familiar enough with the codebase to know if this is right though. If a maintainer could confirm this is a good idea, I can open a PR to implement:
https://github.com/luin/ioredis/blob/eabb70ed835828ad85b602a217992486e05d2218/lib/Command.ts#L315-L317
We can't clear the timeout on rejections because a rejection doesn't necessarily mean a command is failed, instead, the connection can be reconnected and the command can be resent so the idea of commandTimeout is to avoid the command hanging forever waiting for the reconnection.
What's in my mind is to track the timers with a list and clear them when disconnected. Not sure it's worth though.
Fair enough - fwiw we are moving away from using Redis in lambdas, so it won't be a problem for us much longer. I do think it's a genuine problem but understand if the effort to fix isn't worthwhile from your point of view
Yeah I think we can probably clear the timeouts on "flushCommandQueue" which will be called on the "end" event.