getting ESOCKETTIMEDOUT error very frequently

[pottabathini]

We are using node-openid-client for Azure B2C scenarios and able to get the tokenset using manual configuration.

But maximum times when we requesting for access-token, refresh-token by sending authorization-code grant type this library returning below error.

{"code":"ESOCKETTIMEDOUT","message":"Socket timed out on request to login.microsoftonline.com","host":"login.microsoftonline.com","hostname":"login.microsoftonline.com","method":"POST","path":"/tfp/tenantazureb2c.onmicrosoft.com/b2c_1_sign_in/oauth2/v2.0/token"}

How to get ride of this error?

[panva]

Whoa, what's the response time of these APIs? Anyway, openid-client has a timeout on calls set to 1500ms, you can change this configuration like so. If the APIs are unreliable you may also wanna enable retries > see the underlying got library mentioned in the docs and let me know if this fixes your issue. I don't see what else could ;)

[pottabathini]

Thank you for your response. We tried with below settings
b2cIssuer.defaultHttpOptions = { retries: 5, timeout: 10000 }; console.log('httpOptions %j', b2cIssuer.defaultHttpOptions);

But still we are getting the same issue :-(

{"code":"ESOCKETTIMEDOUT","message":"Socket timed out on request to login.microsoftonline.com","host":"login.microsoftonline.com","hostname":"login.microsoftonline.com","method":"POST","path":"/tfp/tenantazureb2c.onmicrosoft.com/b2c_1_sign_in/oauth2/v2.0/token"}

Your library depend on got library to make requests to the server is these httpoption settings will work for that? As I seen it not even wait for that much time and even I don't think it re-trying after we set those options.

[panva]

Yes, all http requests done by the library use these options with the got library. The got library in turn uses node's http/s module, from which this error is coming. ESOCKETTIMEDOUT is not coming from got nor openid-client.

Not sure what your networking setup is, do you have an http/s proxy in your environment, does your user you test manually with have an http_proxy env set and the node user running your client not?

Try to do a plain request to that url using node's https module directly as a first thing in your node process to see whether you get a response from it.

[pottabathini]

Not sure what your networking setup is, do you have an http/s proxy in your environment, does your user you test manually with have an http_proxy env set and the node user running your client not?

We don't have any http/s proxy set in our environment and I am testing with admin privileges

Try to do a plain request to that url using node's https module directly as a first thing in your node process to see whether you get a response from it.

we tried this and it giving the response without fail. We also tried using postman from the same client machine and it also working

Apart from those we tried to set threadpool size and it also failed.
#!/usr/bin/env node process.env.UV_THREADPOOL_SIZE = 128;

If you have time, I can provide you working repo where you can try and reproduce the same issue.

[panva]

wouldn't hurt to dig in

[jiang-12196]

I got this issue too.

[cancerberoSgx]

I found if there are too many async requests, then ESOCKETTIMEDOUT exception happens in linux. The workaround I've found is doing this:

setting this options to request():

agent: false, pool: {maxSockets: 100}

Notice that after that, the timeout can be lying so you might need to increase it. Also in linux you could increase the max number of opened files per process to solve it.