[BUG] Early <Reject> is ignored

[jscheid]

• [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.
• [x] 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:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Reject reason="busy"/>
</Response>

Expected behavior:

The above TwiML code, as the very first response when a call from the Twilio JS client is handled, should trigger some kind of event in the client.

Actual behavior:

The client doesn't appear to emit any events and just hangs. I can see hangup frames on the signalling connection and adding some debug output to Connection.onHangup yields that:

• payload is {"callsid":"CA1a7345ed72e058c3d95682958fd13b29","error":{"code":31000,"message":"General Error"}}
• _this.parameters is { CallSid: "TJS574a820f-59d8-497d-b0bd-473f4aaab43e" }
• _this.outboundConnectionId is also TJS574a820f-59d8-497d-b0bd-473f4aaab43e
• Therefore, the SID from the payload doesn't match and the handler is cancelled in https://github.com/twilio/twilio-client.js/blob/bc4226c3f27575081fee056c8d35c2ce89ca06e4/lib/twilio/connection.ts#L1182

My guess is that the hangup frame arrives at a time when the client's state isn't yet fully initialized and it doesn't know the real call SID yet?

Similar results when reason is rejected.

Software versions:

• [ ] Browser(s): Firefox 88.0.1
• [ ] Operating System: MacOS 10.15.7
• [ ] twilio.js: 1.14.0
• [ ] Third-party libraries (e.g., Angular, React, etc.): not relevant

[jscheid]

I've tried a few ways of working around this, using <Hangup> and with an empty response, but it seems that the only way I can get an event fired is to first play audio (by using <Say> or <Play>).

[jscheid]

This appears to work, but is needlessly noisy:

<Response>
  <Say/>
  <Reject reason="busy"/>
</Response>

[liberty-rowland]

Thank you @jscheid for bringing this up. We will be looking into this further shortly to verify, but I would agree with your hypothesis: it sounds like the error is coming before the client knows the assigned CallSid. I will update this ticket once we've verified and I've cut an internal ticket to address the bug.