graphql-ws: [ReactNative] Slow refresh subscription causes websocket close with {"isTrusted": false, "message": null}

Screenshot Visualising is always helpful.

Working subscription. This one doesn’t authenticate in the backend and seems to work fine. image

Wheras one that does authenticate:

image

As you can see causes ERROR {"isTrusted": false, "message": null} issue. However, the initial graphql subsciption was successful. Giving me back Authenticated data! It’s only the new ones that fail.

Expected Behaviour I expected it to work in react-native. Since my code seems to work quite well in a regular environment,

Actual Behaviour but instead it did ERROR {"isTrusted": false, "message": null}

Debug Information I don’t see any error logs on my backend. Everything seems A OK back there. The only other difference between the two subscriptions in the backend are that the “Hello” one responds every second. While the heartBeat takes 10 seconds.

Further Information I recreated my scenario on a Sandbox that supports react-native. Of course this isn’t the exact environmment. But it works great!

I use expo to compile to Android. Not doing anything too fancy outside the codesandbox example.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 18 (8 by maintainers)

Most upvoted comments

I think the docs should make it mandatory, no?

I don’t think so. Also, we don’t know whats cutting the connection off. Maybe strawberry has something implemented specifically to disconnect after 10 seconds, maybe the underlying Python WS library has a bug, etc.

What scenarios would a default mandatory server side keepAlive be a bad idea? (Of course the value should be configurable if needed as well and even allowed to be turned off.)

No scenario. Having a keep-alive is always good.

Standardizing best practises should include thwarting failure cases for customers/devs who don’t want to get too deep into the spec.

The GraphQL over WebSocket spec is a transport spec, it talks exclusively about transporting GraphQL and how that works within the WebSocket. It’s not a WebSocket spec. I don’t want to convolute it with lower level WS specific things, implementors should have the knowhow about WS to begin with.