Issue requesting key from mainnet verifier

[peterpolman]

My production verifier thx-email-password seems to fail POST requests to https://torus.zilinga.network. This currently breaks our authentication flow since no private key can be fetched for the authenticated user..

POST https://torus.zilliqa.network/jrpc ERR_NAME_NOT_RESOLVED
POST https://torus.zilliqa.network/jrpc ERR_NAME_NOT_RESOLVED
POST https://torus.zilliqa.network/jrpc ERR_NAME_NOT_RESOLVED

The weird thing is that the same code on my staging environment with the staging verifier thx-email-password-staging-verifier gives no issues at all. Any clue what could be up here?

Is it possible to tell DirectAuthSDK client to use an alternative node? The directWebSDK bundle shows me this list:

[
  'https://torus-19.torusnode.com/jrpc',
  'https://torus-node.ens.domains/jrpc',
  'https://torus-node.matic.network/jrpc',
  'https://torus.zilliqa.network/jrpc',
  'https://torus-mainnet.cosmos.network/jrpc',
  'https://torus2.etherscan.com/jrpc',
  'https://torus-node-v2.skalelabs.com/jrpc',
  'https://torus-node.binancex.dev/jrpc',
  'https://torusnode.ont.io/jrpc',
];

As you can see a GET request to https://torus.zilliqa.network/jrpc fails to resolve, while the other nodes are responding as expected.

[peterpolman]

Alright, worked around the errors by making my try..catch a bit more forgiving on the failing requests:)

I noticed that after failing the the 3 POST requests eventually a private key is fetched, so maybe this is just by design and the SDK continues trying the other nodes nonetheless.

[chaitanyapotti]

This is by design. Even if certain nodes fail, as long as threshold number (5 of 9) respond correctly, we proceed with key generation. you can safely ignore node unreachability errors.

There have been some improvements to underlying checks as well. Pls update to v4.14.3 for best performance