"Client is not connected to a websocket"

[booboothefool]

Sorry for the ambiguity, but sometimes I get this error when I start my app.

I am pretty sure I set up most things correctly because I have subscriptions flying all over my app, and it does connect about 90% of the time, but it's a real bummer when it doesn't (nothing realtime works of course) and I have no idea why. :c

[helfer]

@booboothefool I think this might happen if you subscribe when the websocket isn't ready yet. Could you try to submit a failing test case for this? It should be feasible to do so by creating a test case which subscribes as quickly as possible after initializing the client.

[Urigo]

Since #53 merged, there is a new INIT message in the protocol, and new subscriptions are initialized only after init is done.
@booboothefool , Can you please try with the new version? we will release it really soon.

[NeoPhi]

@Urigo I'm not seeing in the code how the INIT message acts as a guard to prevent subscription messages from being sent. Additionally in the case of a reconnect previous subscriptions are reestablished prior to the INIT event firing.

[booboothefool]

@Urigo

I no longer get

Client is connected to a websocket

and it seems to always connect successfully initially, but now instead I am getting an error that reads

INVALID_STATE_ERR

It seems to be a lot worse because it happens much more frequently, and while Client is not connected to a websocket would just error and break subscriptions, INVALID_STATE_ERR crashes my app completely.

I am not sure why this is happening, as it seems completely random. It's like it's dropping the connection. Well when it happens every time I restart my server, so the reconnect might be what's messing it up, but it also happens in production too where my server isn't restarting.

All I did was I upgraded to the new library and changed addGraphQLSubscriptions to the one from the library e.g. import { addGraphQLSubscriptions } from 'subscriptions-transport-ws'; instead of https://github.com/apollographql/GitHunt-React/blob/master/ui/helpers/subscriptions.js. Is there anything important that I missed?

My subscriptions look something like this (based on http://dev.apollodata.com/react/receiving-updates.html#Subscriptions):

  componentWillReceiveProps(newProps) {
    const { user } = this.props;
    if (!newProps.data.loading) {
        if (this.subscription) {
          if (
            // if the feed has changed, we need to unsubscribe before resubscribing
            newProps.data.favoritedYou !== this.props.data.favoritedYou ||
            newProps.data.visitedYou !== this.props.data.visitedYou
          ) {
            this.subscription.unsubscribe();
          } else {
            // we already have an active subscription with the right params
            return;
          }
        }
        this.subscription = [
          newProps.data.subscribeToMore(newFavorites(user)),
          newProps.data.subscribeToMore(newVisitors(user)),
        ];
    }
  }

[NeoPhi]

@booboothefool I've noticed that with native WebSockets I'm seeing the client disconnect and reconnect more often. On the server do you have the keepAlive option set? If not does setting it to something like 20000 help reduce the incidence?

[booboothefool]

@NeoPhi cool so:

0.3.1 => "Client is not connected to a websocket" (no subscriptions work)
0.5.0 => "INVALID_STATE_ERR" (crashes app)

Then I upgraded to 0.5.1 and did what you suggested setting keepAlive: 20000 on the server, and it seems like it works great now. Client always connects successfully and it hasn't crashed me with INVALID_STATE_ERR in 2 days. Overall happy with it because this is the best I've seen my subscriptions work. 👍

Can you explain what that does and how it solves the problem (and what the problem actually is)?

[NeoPhi]

Without keepAlive unless you have traffic constantly flowing across the WebSocket you are probably hitting a connection timeout with a proxy or firewall.

I've not walked through the code but I suspect that there is a race condition between the WebSocket reconnecting and the previously active subscriptions being reestablished such that the client thinks it is okay to send a message when in fact it shouldn't, resulting in the error

[sairamdevarashetty]

+1
@Urigo

facing the same error again using version 0.5.5

[vladinator1000]

To more easily debug issues like this, please look at the Network -> Frames tab in Chrome devtools. That's where any errors would be.