RestException Authentication Error is thrown twice and can not be catched (for flows.list())

[machinaeXlasse]

Issue Summary

With a twilio client connected with valid but incorrect sid and/or token when I try to list studio flows using

client.studio.v2.flows.list

I can catch a first RestException [Error]: Authentication Error - invalid username which is expected behaviour.

Then the same error is thrown again inside some unknown async process. Since I have no acces to the hidden async process I can not catch this second error.

The same goes for using the callback and awaiting the promise of client.studio.v2.flows.list.

Steps to Reproduce

1. Create a client with valid but incorrect sid and token.
2. make an API call to list studio flows and catch any errors

Code Snippet

const client = require('twilio')("ACxxx", "xxx")

client.studio.v2.flows.list((err, flows) => {
    if(err) {console.log(""FIRST EXPECTED ERROR", err)}
    flows.forEach(flow => {
      console.log(flow.friendlyName)
    })
})

Exception/Log

FIRST EXPECTED ERROR RestException [Error]: Authentication Error - invalid username
    at FlowPage.processResponse (...\node_modules\twilio\lib\base\Page.js:135:19)
    at new Page (...\node_modules\twilio\lib\base\Page.js:17:28)
    at new FlowPage (...\node_modules\twilio\lib\rest\studio\v2\flow.js:305:9)
    at ...\node_modules\twilio\lib\rest\studio\v2\flow.js:272:63
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  status: 401,
  code: 20003,
  moreInfo: 'https://www.twilio.com/docs/errors/20003',
  details: undefined
}
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

RestException [Error]: Authentication Error - invalid username
    at FlowPage.processResponse (...\node_modules\twilio\lib\base\Page.js:135:19)
    at new Page (...\node_modules\twilio\lib\base\Page.js:17:28)
    at new FlowPage (...\node_modules\twilio\lib\rest\studio\v2\flow.js:305:9)
    at ...\node_modules\twilio\lib\rest\studio\v2\flow.js:272:63
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  status: 401,
  code: 20003,
  moreInfo: 'https://www.twilio.com/docs/errors/20003',
  details: undefined
}

Technical details:

• twilio-node version: 4.11.0
• node version: v18.14.2
• OS: Windows 10

[machinaeXlasse]

Same issue seems to be the case for client.messages.list()

[AsabuHere]

Hi @machinaeXlasse , This issue has been added to our internal backlog to be prioritised. Pull requests and +1s on the issue summary will help it move up the backlog.

[machinaeXlasse]

Great! Thanks a lot.

For a potential temporary fix: Do you know an alternative way how I could check if a connection could be established with given sid and token?

[silentjohnny]

The issue of duplicate exceptions being thrown seems to be caused inside the Page module, and hence occurs with any exception thrown by Pageable result sets.

For example:

const client = require('twilio')("ACxxx", "xxx")

try {
  const usage = await client.api.account.usage.records.monthly.list({
    category: 'totalprice', 
    includeSubaccounts: true, 
    new Date('2018-01-01'), 
    new Date('2018-12-01') 
  })
} catch (err) {
  console.log(err.message)
}

Since there are no records for 2018, an exception is thrown

The requested resource /2010-04-01/Accounts/ACxxx/Usage/Records/Monthly.json was not found

But imediately after that:

RestException [Error]: The requested resource /2010-04-01/Accounts/ACxxx/Usage/Records/Monthly.json was not found
      at MonthlyPage.processResponse (node_modules/twilio/lib/base/Page.js:135:19)
      at new Page (node_modules/twilio/lib/base/Page.js:17:28)
      at new MonthlyPage (node_modules/twilio/lib/rest/api/v2010/account/usage/record/monthly.js:144:9)
      at node_modules/twilio/lib/rest/api/v2010/account/usage/record/monthly.js:63:63
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
    status: 404,
    code: 20404,
    moreInfo: 'https://www.twilio.com/docs/errors/20404',
    details: undefined

Hope this helps drill down the cause.

[highstrungscorpio]

Anyone figure out a workaround? Perhaps downgrading the twilio-node version or node version? We recently updated the version we are using of both and now I am seeing this issue

try {
    const usageResponse: UsageRecordInstance[] = await client.wireless.v1.sims(SID)
         .usageRecords.list({
            start: start,
            end: end
         })

         const usageRecord = usageResponse[0] 

         let dataTotal = 0
         if (usageRecord) {
            dataTotal = (usageRecord.data?.total === null) ? 0 : usageRecord.data?.total
         }
         return dataTotal
     } catch (err: any) {
         console.error(err)
         return 0
    }

The error I see is:

RestException [Error]:Value is of the wrong SID type
    at UsageRecordPage.processResponse (C:\Dev\saige\backend\node_modules\twilio\lib\base\Page.js:135:19)
    at new Page (C:\Dev\saige\backend\node_modules\twilio\lib\base\Page.js:17:28)
    at new UsageRecordPage (C:\Dev\saige\backend\node_modules\twilio\lib\rest\wireless\v1\sim\usageRecord.js:122:9)
    at C:\Dev\saige\backend\node_modules\twilio\lib\rest\wireless\v1\sim\usageRecord.js:61:63
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  status: 422,
  code: 422,
  moreInfo: 'https://www.twilio.com/docs/errors/422',
  details: undefined
}

[markbussard]

I too am seeing an issue when calling a method which utilizes the Page module. In my case I am trying to list out conversations for a particular user who doesn't yet exist. And while I am catching the error, another seems to be getting thrown that crashes our server (as others have stated)

RestException [Error]: The requested resource /Users/****/Conversations was not found

[machinaeXlasse]

As far as I can test the problem has been fixed in the meantime. Could not find a changelog so not sure at what point.

Updating to twilio npm package 4.19 solved it for me.

[silentjohnny]

This was fixed in 4.15.0 by PR #952, I guess this issue can be closed.