Subscriptions-transport-ws: WebSocket connection closing occasionally

[gijo-varghese]

After building a VueJS app with Apollo Server graphql and vue-apollo for the client, the socket is occasionally disconnected on the first load itself. (It won't happen every time, maybe once in every 5-10 loads). Whats the reason for this?

[mxstbr]

We're experiencing the same thing, I think it was due to #368—that was released yesterday in 0.9.7, mind updating to that and letting me know if it still happens?

[gijo-varghese]

Ok. Let me try downgrading. Which version do you prefer?

[mxstbr]

Upgrading, not downgrading! I think #368 fixes it, sorry for the bad wording there

[gijo-varghese]

Already using 0.9.7. The issue still exists :(

[gijo-varghese]

@mxstbr do you think its a handshake timeout?

[gijo-varghese]

Finally

link.subscriptionClient.maxConnectTimeGenerator.duration = () => link.subscriptionClient.maxConnectTimeGenerator.max

That fixed the issue

Thanks to https://github.com/apollographql/subscriptions-transport-ws/issues/377

[mxstbr]

Hmm interesting, how could we/should we implement this by default? Mind submitting a PR so we can discuss?

[gijo-varghese]

I think we should increment the default handshake from 1 request to 3/5 seconds. Also make it available as an option to set, so that users can specify their own timeout for the handshake. What do you think?

[mxstbr]

I don't know, I'm not familiar with the problem domain! Submit a PR, explain your reasoning and then we can discuss—it's hard for me to say without looking at a patch :blush:

[gijo-varghese]

Sure. I'm at the end of a product deployment. I'll send it soon :)

[mxstbr]

Awesome, thank you!

[gijo-varghese]

Figured out one more thing. We've to add lazy: true. Otherwise the same error will occur

[mxstbr]

PRs very welcome!

[arsanjea]

hey @gijo-varghese . While the fix mentioned in https://github.com/apollographql/subscriptions-transport-ws/issues/377 make things better, the subscription client still disconnects every 30-45 seconds, which makes for a pretty poor experience for my customers :/

[gijo-varghese]

@arsanjea I just checked. For me, it's not disconnecting after 30-45 secs. Are you sure?

[arsanjea]

@gijo-varghese yeah, does. But I am not using lazy: true since I won't be able to use my fix if the client is not instantiated right away.
Would you mind sharing your instentiation code?

[gijo-varghese]

@arsanjea You can check it here: https://goo.gl/NHA3Fu

here is the code that i use:

import VueApollo from "vue-apollo";
import { ApolloClient } from "apollo-client";
import { HttpLink } from "apollo-link-http";
import { InMemoryCache } from "apollo-cache-inmemory";
import { split } from "apollo-link";
import { WebSocketLink } from "apollo-link-ws";
import { getMainDefinition } from "apollo-utilities";

const httpLink = new HttpLink({
  uri: process.env.GRAPHQL_URL
});

const wsLink = new WebSocketLink({
  uri: process.env.GRAPHQL_WS_URL,
  options: {
    reconnect: true,
    lazy: true
  }
});

wsLink.subscriptionClient.on("connecting", () => {
  console.log("connecting");
});

wsLink.subscriptionClient.on("connected", () => {
  console.log("connected");
});

wsLink.subscriptionClient.on("reconnecting", () => {
  console.log("reconnecting");
});

wsLink.subscriptionClient.on("reconnected", () => {
  console.log("reconnected");
});

wsLink.subscriptionClient.on("disconnected", () => {
  console.log("disconnected");
});

wsLink.subscriptionClient.maxConnectTimeGenerator.duration = () =>
  wsLink.subscriptionClient.maxConnectTimeGenerator.max;

const link = split(
  ({ query }) => {
    const { kind, operation } = getMainDefinition(query);
    return kind === "OperationDefinition" && operation === "subscription";
  },
  wsLink,
  httpLink
);

const apolloProvider = new VueApollo({
  defaultClient: new ApolloClient({
    link,
    cache: new InMemoryCache(),
    connectToDevTools: true
  })
});

export default apolloProvider;

[arsanjea]

the lazy option seems to be working for me...fingers crossed! I am only encountering the issue in my beta and production environments where the servers sit behind a load balancer and use wss (vs. ws in my development environment).

[gijo-varghese]

@arsanjea which version of subscriptions-transport-ws are you using in client and server?

Its working fine is localhost and problem occurs only in production servers right? From my finding, the handshake timeout is under 1 sec. So localhost it won't be a problem, but in production sometimes it may take more than 1 sec, hence everything fails.

Is there any way I can test it? Maybe I can help

[gijo-varghese]

@arsanjea This one https://goo.gl/NHA3Fu is working fine as expected, right?

[NeoPhi]

@arsanjea Are you using the keep alive feature? I've observed various load balancers and proxies shutting down the WebSocket if there is no activity in a certain amount of time. We use a keep alive of 25 seconds with good results.

[gijo-varghese]

I use a keep alive of 10 seconds

[slawomir-brzezinski-at-clarksons]

The original reporter mentions this happens on initial connection, and reported that #377 fixed the issue.
Therefore, I suggest closing this as duplicate of #377 (and addressing that one as per my suggestion 😄).

Regarding the 'in-use' disconnections, like in @arsanjea's comment, I suggest to move discussion to #483, which also fights with a similar issue and no one reported #377 as a remedy so far.

[HugoLiconV]

Any other suggestions? any of this is working for me, I'm getting disconnected every minute:

04:57:15 connecting
04:57:15 connected
04:58:16 disconnected
04:58:17 reconnecting
04:58:17 reconnected

[DominicTobias-b1]

My websocket went in an infinite reconnection loop with reconnect: true when redirecting from the login page as we close the connection in order to update the auth header, using lazy fixed it though I don't know why 🤔 Edit: lazy stopped it working properly, using wsClient.client.close() works a little better

[AndrewYefimenko]

@HugoLiconV Looks like you set reconnect on client but your server is not sending "ka" (keep-alive) messages.

[geiszla]

We are also experiencing this problem, but on the web (so issues referred by https://github.com/apollographql/subscriptions-transport-ws/issues/381#issuecomment-448654136 do not apply). It successfully reconnect, but because of this, we get many false onDisconnect events on the server and potentially lose subscriptions, because they aren't sent on the new connection.