Node-ldapjs: client.bind() never responds if server can't be reached (timeouts have no effect)

[randomsock]

Long story short, if your server is currently down, a client.bind() never responds (meaning the callback is never called). Setting the connectTimeout and timeout on ldapjs.createClient() seem to have no effect at all here.

We first noticed this when a server went down after our app had already bound and the app then started hanging, so I'm assuming ldapjs was trying to re-bind after the connection fail[?]. I mention this because the knock on effect is that upstream client.search()s suddenly stop responding.

Reproducible like this, assuming the IP address here is valid but not responding:

> var ldapjs = require('ldapjs')
> var client = ldapjs.createClient({url:'ldap://10.146.241.10:1389', timeout:3000, connectTimeout:3000})
> client.bind(myDN, myPassword, function(err) { console.log('bind', err); });
> // ...tumbleweeds...

[pfmooney]

I believe your request is falling into the built-in request buffer that ldapjs provides. Many consumers call request methods immediately after constructing a client despite the fact that it isn't connected. Doing so would normally result in a failure (it's difficult to perform a bind without a valid socket) so the requests are queued in a buffer. For the sake of simplicity, per-request timeouts are calculated only for actions that take place on the socket.

While the option still must be documented, the request queue can be disabled with the disableQueue option when construction a client. This will cause requests to _immediately_ fail with an error if the client socket is not ready.

[goodpilotfish]

Correction to the response by @pfmooney. The undocumented option is now called queueDisable

[maneeshmohan2000]

When the LDAP server is down and if I set the queueDisable option to false, this works fine and give me the error "{ [ConnectionError: connection unavailable] lde_message: 'connection unavailable
', lde_dn: null }". But, this is always throwing the same error when the LDAP server is up also and if I comment out the queueDisabled option, it works.
I am wondering why this is behaving like this.

[bosiam]

But, this is always throwing the same error when the LDAP server is up also and if I comment out the queueDisabled option, it works.
I am wondering why this is behaving like this.

[alvinlee001]

@maneeshmohan2000 and @bosiam is right, seems it is unable to connect to ldap, despite whether ldap server is up or not, if queueDisabled is set to true. The problem seem to still exist until this date.

[danperks]

Issue is still present now

[UziTech]

@danperks if you could create a new issue and provide code that reproduces this we could help find the solution.