[BUG] Release Notes for enableImprovedSignalingErrorPrecision flag error codes are incorrect

[aburkowsky9]

• [X] I have verified that the issue occurs with the latest twilio.js release and is not marked as a known issue in the CHANGELOG.md.
  • [X] I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
  • [ ] I verified that the Quickstart application works in my environment.
  • [X] I am not sharing any Personally Identifiable Information (PII) or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Code to reproduce the issue:

// TODO

Expected behavior: Device error codes that match those stated in the latest release notes using the enableImprovedSignalingErrorPrecision flag: https://github.com/twilio/twilio-voice.js/releases/tag/2.8.0

Actual behavior:

I have not seen any change in Device error codes after using the new enableImprovedSignalingErrorPrecision flag. In fact I see what is stated to be a legacy call error code 31005 at the top level and the legacy device error code 53000 in the deeper twilioError object. This is the exact same with the flag on and off. I never see the reported newly implemented error codes.

The following is captured using the device event listener for error -

      device.on(Device.EventName.Error, (e: TwilioError.TwilioError) => {
        console.error(
          'A device error has occurred: ',
          JSON.stringify(e, null, 2),
        );
     }

Software versions:

• [X] Browser(s): Chrome v119.0.6045.123
• [X] Operating System: Mac OS 13.5.2
• [X] twilio.js: 2.8.0
• [X] Third-party libraries (e.g., Angular, React, etc.): React 18.2.0

[mhuynh5757]

Hey @aburkowsky9, thanks for the detailed write-up, it's very much appreciated. We should clarify that error 31005 is not phased-out or legacy, but that there are now alternative error codes when applicable. To explain, if the SDK can describe an error more precisely, it will attempt to do so. But if there is no "more precise" error, then the SDK will still emit 31005. For example, when the websocket connection is lost due to network failure. The browser does not give much information on why the websocket is lost, and we fall back to generic error code 31005. Is there any special case to reproduce the error that you're seeing?

[aburkowsky9]

Thanks for clarifying @mhuynh5757. I reproduce this case by putting my computer to sleep when the device is instantiated and registered.