Reconnect doesn't work after Safari drops WebSocket connection when the user locks the screen on a mobile device.

[SerhiiZvinskyi-q4inc]

Repro steps
Using any of client examples from here https://www.npmjs.com/package/graphql-ws

• Open the page in Safari on iPad. WebSocket connection established. Everything is up and running;
• Lock the screen of the device. Wait a few seconds;
• Unlock the screen. In fact we stop seeing any activity within WebSocket connection. The last thing was ping message. Furthermore in JS socket interpreted as opened, but it doesn't react on any action like .send(), .close() etc.

The issue might be reproduced on iPad/iPhone running Safari browser. It seems Safari freeze the app memory and socket itself.. https://stackoverflow.com/questions/24796103/keep-websocket-alive-in-mobile-safari

Expected Behaviour
It should reconnect

Actual Behaviour
It does nothing

Further Information
Personally I'm using the following simple app to reproduce the issue...

const client = createClient({
      url: "ws://localhost:4001/graphql",
      lazy: true,
      keepAlive: 10_000,
      retryAttempt: 30,
    });

    let activeSocket,
      timedOut;

    client.on("opened", (socket) => {
      activeSocket = socket;
    });

    client.on("connected", () => {
    });

    client.on("ping", (received) => {
      if (!received /* sent */) {
        timedOut = setTimeout(() => {
          if (activeSocket.readyState === WebSocket.OPEN) {
            activeSocket.close(4205, "Service Restart");
            // here I assume that client will re-connect but it's not. because after unlock the screen the socket freezes.
          }
        }, 5_000); // wait 5 seconds for the pong and then close the connection
      }
    });
    client.on("pong", (received) => {
      if (received) {
        clearTimeout(timedOut); // pong is received, clear connection close timeout
      }
    });
    client.on("message", console.log);
    client.on("error", console.log);

    client.subscribe({...});

Before graphql-ws I was using subscriptions-transport-ws and it handles such scenarios well.
Unfortunately I can't even do proper workaround as far as graphql-ws doesn't provide connect method as it's encapsulated.

Moreover I found workaround like this. I'm not sure it's the best one. I would prefer graphql-ws to do this for me.

if (activeSocket.readyState === WebSocket.OPEN) {
    activeSocket.close(4205, "Client Restart");
    if (isMobile /* phone or tablet */ && browserTabActive) {
        window.location.reload();
    }
}

[enisdenjo]

This is certainly an issue with Safari. If the OS/browser does not communicate a close event, there's absolutely no way graphql-ws can know the connection is gone and act accordingly.

Furthermore, the connect method is intentionally not exposed since the library should control the connection since there are many factors deciding when to connect.

Moreover I found workaround like this. I'm not sure it's the best one. I would prefer graphql-ws to do this for me.

The way you handle it is the way I'd recommend handling it.

Please keep in mind that graphql-ws is isomorphic; meaning, it runs both in the browser and Node. Having said this, the library must not depend on the window global since it is only available in the browser. It is up to the implementer to handle the quirks of the environment he's targeting. In essence, you're the one that has to bridge the gap.

Before graphql-ws I was using subscriptions-transport-ws and it handles such scenarios well.

Can you elaborate a bit more on how does subscriptions-transport-ws handle this scenario?

[SerhiiZvinskyi-q4inc]

checkConnection() calls the private method .close() with the first argument false, then .close() calls .tryReconnect() and inside you can find .connect() call that actually makes new connection via new this.wsImpl(this.url...
Thus, it doesn't care about the previous connection that can't respond with a keep-alive message ( pong message in graphql-ws)

So, the flow is the following:
https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/client.ts#L533 >
https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/client.ts#L540 >
https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/client.ts#L182 >
https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/client.ts#L522 >
https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/client.ts#L557

[enisdenjo]

I follow, thanks.

The thing is, graphql-ws advocates WebSocket protocol level pings and pongs, which are enabled and used by default. Sadly, there's no "onPing" handler in browsers for these pings which kinda complicates things.

Still, I have an iOS device myself. When I have time, I will play around and see if there's something we can do that handles these issues out-of-the-box.

In the meantime, Googling around surfaced these:

• https://github.com/richtr/NoSleep.js
• https://coderedirect.com/questions/552737/keep-websocket-alive-in-mobile-safari (use socket.setKeepAlive(true, 2000))

could they possibly be of help?

[SerhiiZvinskyi-q4inc]

Thanks,

NoSleep is helpful. It just plays the audio and it prevents WebSocket to become inactive. It's strange but it works with iOS ;-)

I've tried socket.setKeepAlive() but it doesn't work in the browser.

[enisdenjo]

Awesome!

I'll still take a look myself and try to integrate a fix, if possible.

However, holidays are approaching and since NoSleep tackles the issue - I'll come back to this sometime in January 2022. Hope this is OK with you. 😄

[SerhiiZvinskyi-q4inc]

No problem. It's okay to me. Thanks.

[enisdenjo]

This problem is specific to Safari and seems like NoSleep.js does the trick of keeping the socket alive, but it comes with a cost as described in #290 (reply in thread).

I will be looking into integrating a solution into graphql-ws; however, this is not that straight forward as mentioned briefly in #290 (comment). Please consult the "Client usage with abrupt termination on pong timeout" recipe.

[flipace]

@enisdenjo any idea when this could be tackled? or some guidance on how you'd approach a fix for this (so we could maybe help out)?

[enisdenjo]

I don't think there even is a way of tackling this isomorphically in the lib. Suggestions are welcome, but I don't have any clues as of right now.

I would use NoSleep.js or do something similar to what subscriptions-transport-ws did, issue pings and if there are no pongs - close the connection (see "Client usage with ping/pong timeout and latency metrics" recipe).

Furthermore, I'd recommend the former, NoSleep.js approach, because it will more reliably keep the connection alive and allow the browser to process messages while in the background. Which brings me to the question: do you have problems with NoSleep.js or are you just checking whether a built-in solution is viable?

[flipace]

Okay, thanks for the quick answer @enisdenjo 👍

We tried NoSleep.js on iOS however it displays the media playback interface (as expected) in the "notification" interface (with media name "No Sleep") so this could lead to questions from users 😅

For our (hybrid) native iOS app (using Capacitor) we're going to try using a keep awake solution where it's going to disable the idle timer for the app. But that won't work for the web safari version of course.

Apart from that, we implemented the ping/pong + forced close of the connection. BTW, we found that in some cases the "frozen" socket connection not only occurred after sleep mode, but also when the network was flaky and changed between online and offline state . It would eventually no longer react. (Our QA team is fantastic and sometimes drives us into insanity 💚 )

OT - A note here for others: depending on how long the connection is gone, by default graphql-ws is using a retry backoff strategy which can lead to extremely (infinitely) long retry timeouts (see

graphql-ws/src/client.ts

Line 442 in 33de8f6

retryWait = async function randomisedExponentialBackoff(retries) {

).

It took us some time to find this default strategy and replace it with a custom one (even though there's an example for the custom strategy in the README.md). We removed the randomization + added a MAX_RETRY_DELAY to ensure that we won't exceed it. Also, whenever we detect a network change, we reset this delay to retry ASAP and not have the user wait until the next retry is scheduled.

(Last but not least - thank you for this library, it's really great. I like how well designed and commented it is + the "no bullshit" structure of the README.md)

[enisdenjo]

Well, I can relate to insanity!

Whatever the case is, at least handling frozen WebSockets is something the lib should offer out-of-the box as its occurrence can be seen as completely normal. Nevertheless, I think you'll (and also @SerhiiZvinskyi-q4inc) like version v5.7.0. 😉

[flipace]

Oh my, that's awesome! Thanks for the update 🎉

[efstathiosntonas]

Thanks for this folks, can you please provide share an example on how to use this with ApolloClient? Thanks!

edit: nvm, figured it out:

let timedOut: any;

    const wsLink = new GraphQLWsLink(
      createClient({
        url: "wss://xxxxx",
        lazy: true,
        on: {
          ping: (received) => {
            if (!received /* sent */) {
              timedOut = setTimeout(() => {
                // a close event `4499: Terminated` is issued to the current WebSocket and an
                // artificial `{ code: 4499, reason: 'Terminated', wasClean: false }` close-event-like
                // object is immediately emitted without waiting for the one coming from `WebSocket.onclose`
                //
                // calling terminate is not considered fatal and a connection retry will occur as expected
                //
                // see: https://github.com/enisdenjo/graphql-ws/discussions/290
                wsLink.client.terminate();
              }, 5_000);
            }
          },
          pong: (received) => {
            if (received) {
              clearTimeout(timedOut);
            }
          },