FetchError: Unhandled promise rejection (ENOTFOUND)

[bennycode]

I tested the Binance API in a real-world scenario where internet connections can get interrupted. In these cases, the "binance-api-node" library fails with a Unhandled promise rejection which can cause Node.js application crashes.

Here is a little code demo which shows the issue:

const Binance = require('binance-api-node').default
const dotenv = require('dotenv')

if (!process.env.BINANCE_API_KEY) dotenv.load()

process.on('unhandledRejection', error => {
  console.error('Catched Binance error', error)
  process.exit(1)
})

const client = Binance({
  apiKey: process.env.BINANCE_API_KEY,
  apiSecret: process.env.BINANCE_API_SECRET,
})

async function getOrder() {
  const order = await client.getOrder({symbol: 'TRXETH', orderId: 20123533})
  console.log(`order (${Date.now()})`, order)
  setTimeout(getOrder, 2000)
}

getOrder()

Just run the code and turn off your internet connection (airplane mode) while the code is running.

We need to come up with a concept, where this scenario is detected and where Promises will be continued once internet is back again.

[bennycode]

Investigation: We can make use of our own error.code which will be ENOENT or ENOTFOUND in this case!

Small workaround:

const Binance = require('binance-api-node').default
const dotenv = require('dotenv')

process.on('unhandledRejection', error => {
  console.error('Catched Binance error', error)
  process.exit(1)
})

if (!process.env.BINANCE_API_KEY) dotenv.load()

const client = Binance({
  apiKey: process.env.BINANCE_API_KEY,
  apiSecret: process.env.BINANCE_API_SECRET,
})

async function getOrder() {
  try {
    const order = await client.getOrder({symbol: 'TRXETH', orderId: 20123533})
    console.log(`order (${Date.now()})`, order)
  } catch (error) {
    if (['ENOENT', 'ENOTFOUND'].includes(error.code)) {
      console.log('Waiting for internet to come back...')
    } else {
      throw error
    }
  } finally {
    setTimeout(getOrder, 2000)
  }
}

getOrder()

I tested this workaround for some time but sometimes I still receive the following error:

Error: Timestamp for this request is outside of the recvWindow.

@balthazar: Do you have any idea how we can tackle the recvWindow error?

[balthazar]

This second error is most likely due to your computer having an out-of-sync clock, maybe you should try updating it.

As for how to handle this case maybe we should catch the ENOENT and ENOTFOUND and throw a more meaningful error that we could include in our error map. The try catch approach seems like the preferred solution anyway, but we need to catch these connectivity errors of websockets too.

[bennycode]

The Timestamp for this request is outside of the recvWindow often happens, when I go offline and go back online. I think it's related to this. Can it be that the request gets cached and is too old, when I come back online?

[bitcoinvsalts]

I am also getting Timestamp for this request is outside of the recvWindow any idea why?

[balthazar]

@bennyn Most likely it if it doesn't error out before the connection goes back on

[bennycode]

I will close the issue here because we now export ErrorCodes and based on them the using application can retrigger certain API calls.

@jsappme The "Timestamp for this request is outside of the recvWindow" issue will be tackled in this issue: #80 - Please also try to use the useServerTime property, it might already fix your issue. 😃