[GUACAMOLE-1015] tunnel and websocket states out of sync

• Type: Bug
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 1.1.0
• Component/s: guacamole-common-js
• Assignee: Unassigned
• Reporter: AJ Funk
• Created: 07/Apr/20 05:54
• Updated: 11/May/20 19:47

Description

When using the WebSocketTunnel, we are constantly seeing the error: "InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state." being thrown.

The identify the issue, we added some extra logging information by overriding the sendMessage method and wrapping it with a try/catch like this:

const websocketTunnel = this.websocket = new Guacamole.WebSocketTunnel(`wss://${domain}/guacamole/${guacWsPort}`);

const guac = this.rfb = new Guacamole.Client(this.websocket);
// wrap sendMessage with a try/catch for debugging

const originalTunnelSendMessage = websocketTunnel.sendMessage;
this.websocket.sendMessage = (...args) => {
  try {
    originalTunnelSendMessage.apply(this.websocket, args);
  } catch (e) {
    if (window.Sentry) {
      const clientState = guac.getState();
      const tunnelState = websocketTunnel.state;
      const socketState = websocketTunnel.socket.readyState;
      window.Sentry.withScope(scope => {
        scope.setTag("origin", "guac socket");
        scope.setExtra("args", args);
        scope.setExtra("clientState", clientState);
        scope.setExtra("tunnelState", tunnelState);
        scope.setExtra("socketReadyState", socketState);
        window.Sentry.captureException(e);
      });
    }
  }
}

(we use https://sentry.io to capture exceptions)

This provided the following values:
clientState: 2 (STATE_WAITING)
tunnelState: 3 (UNSTABLE)
socketReadyState: 0 (CONNECTING)
We managed to apply a patch to silence this error. On this line https://guacamole.apache.org/doc/1.1.0/guacamole-common-js/Tunnel.js.html#line379

we changed

if (!tunnel.isConnected())

to check the socket's state instead of the tunnel's:

if (!socket || socket.readyState !== WebSocket.OPEN )

 

We determined that this error was non-critical since it did not disrupt the client's websocket connection, but it caused a lot of noise with thousands of error events.