[Bug]: Firefox WebSocket HTTP/2 Issue: App Malfunction When Engine Started and Stopped Multiple Times

[shareefalis]

What happened?

On Firefox with WebSocket HTTP/2 enabled, our web app encounters errors in the streaming Speech-to-Text (STT) feature when the engine is started and stopped three times. Attempting to start the engine again results in a library error displayed in the console. Disabling HTTP/2 resolves this issue, restoring the app's functionality.

We prevent user error by enforcing a requirement for the user to wait until the engine reports a 'started' or 'stopped' state before allowing them to start or stop the engine.

Version

1.34.0

What browser/platform are you seeing the problem on?

No response

Relevant log output

Error: {"privSessionId":"3F9C187A3AC0452CB78903369A792D38","privReason":0,"privErrorDetails":"The number of parallel requests exceeded the number of allowed concurrent transcriptions.","privErrorCode":3}

[glharper]

@shareefalis Thank you for using JS Speech SDK, and writing this issue up. Which region are you seeing this behavior? Could you try with eastus or eastus2?

[shareefalis]

Hello Glenn, we are seeing this behavior on eastus2

[glharper]

Hello Glenn, we are seeing this behavior on eastus2

It seems strange that disabling http2 websocket connections affects an error stating that "The number of parallel requests exceeded the number of allowed concurrent transcriptions." Could you describe what happens to the existing recognizer instance when you stop your app's engine?

[shareefalis]

We assign a undefined value if the engine is stopped and we recreate the engine in start by a new SpeechRecognizer

[shareefalis]

      this.setState(SpeechToTextClientStates.STOPPING_STATE);
      this.recognizer.stopContinuousRecognitionAsync(
        () => {
          this.setState(SpeechToTextClientStates.STOPPED_STATE);
          this.recognizer = undefined;
        },
        (err: string) => {
          this.setState(SpeechToTextClientStates.STOPPED_STATE, new Error(err));
          this.recognizer = undefined;
        },
      );

[glharper]

Try calling this.recognizer.close() before setting it to undefined.

[shareefalis]

I tried it. it works now.. Strange to why it is happening now with the new behavior

[glharper]

I tried it. it works now.. Strange to why it is happening now with the new behavior

That close() call lets the backend service know that the client is ending the recognition session. Without it, it takes a few minutes (or more) of inactivity before the service gives up and closes the websocket.