Subscription stays active after successful subscription stop call (GQL_STOP message)

[viktor-br]

Subscription stays active after successful subscription stop call, when a subscription start call (GQL_START message) is not completed before subscription stop call.
See schema below.

Happy case:

subscription start:  |-----|
subscription stop:            |----|
send message:                               |-----|
receive message:                                      [no message is sent via subscription]

Issue case:

subscription start:  |------------------|
subscription stop:            |----|
send message:                               |-----|
receive message:                                      |-------| <- message was send via subscription

I created a repository with an example how to reproduce the issue https://github.com/viktor-br/subscriptions-transport-ws-reproduce-issue/

Repository contains simple server and client, which start two long starting subscriptions, unsubscribe in the middle from one of them, then trigger subscription resolvers.

Also i added a patch file https://github.com/viktor-br/subscriptions-transport-ws-reproduce-issue/blob/master/patches/subscriptions-transport-ws%2B0.9.16.patch to avoid creating subscription if it was stopped in the middle of starting.

If it makes sense, i can create pull request with the fix and tests. Or maybe fix should be implemented in other way.

[atondelier]

Hello,

I've been studying an issue we are having with graphql subscriptions, powered by subscriptions-transport-ws as the transport layer. The subscriptions, mounted dynamically by our React application happen to be created a "random" amount of times during the component mounting/first updates phases.

While this results in the correct sending of START and STOP signals over the wire from the frontend to the backend, some subscriptions are actually never stopped server side. Actually the server receives these STOP signals, but, before the subscription setup reaches a state where it exposes the objects for stopping it.

In such a case, only the complete disconnection of the client triggers all the ghost subscriptions end. I did not try the corner case of a disconnection right after a START signal.

I'll try your patch and confirm you if it works fine.