Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some subscriptions remain open after a websocket has been closed #532

Closed
andreasdamm-shure opened this issue Feb 9, 2024 · 2 comments · Fixed by #534 · May be fixed by a11ywatch/core#429
Closed

Some subscriptions remain open after a websocket has been closed #532

andreasdamm-shure opened this issue Feb 9, 2024 · 2 comments · Fixed by #534 · May be fixed by a11ywatch/core#429
Labels
bug Something isn't working released Has been released and published

Comments

@andreasdamm-shure
Copy link

Expected Behaviour
When a client closes a websocket then all subscriptions (i.e. async iterables) on the server side need to have their return method called (if defined) regardless of whether the client sent an unsubscribe message before closing the websocket.

Actual Behaviour
Some subscriptions remain open on the server after the websocket has been closed.

Debug Information
When a subscription request is received, the asynchronous subscribe resolver of the executable schema is ultimately called.

const maybeResult = await onOperation?.(

Once the returned promise is resolved a subscription entry is made in ctx.subscriptions.

ctx.subscriptions[id] = operationResult;

If the promise is resolved after the websocket close handler has been called the an entry is still made in ctx.subscriptions and its return method will never be called.

Depending on the subscription object leakage of memory and resources can ensue.

Further Information
Here is an example program: post-close-subscription-bug.zip

Run yarn install followed by yarn start and open a browser window for http://localhost:4000/graphql. Start a subscription in that window :--

subscription {
  never
}

then close the browser window (without stopping the subscription first) within less than five seconds of establishing the subscription.

Open another browser window for http://localhost:4000/graphql and run

query {
  count
}

A count of 1 should be returned.

Repeating the same process but waiting at least five seconds before closing the subscription browser window should not lead to an increase of the count.

@enisdenjo
Copy link
Owner

Wow great catch! I've managed to create a failing test replicating what you've described. Thanks for reporting it! Fix coming soon.

@enisdenjo enisdenjo added the bug Something isn't working label Feb 12, 2024
enisdenjo added a commit that referenced this issue Feb 12, 2024
enisdenjo pushed a commit that referenced this issue Feb 12, 2024
# [5.15.0](v5.14.3...v5.15.0) (2024-02-12)

### Bug Fixes

* **client:** Use `TerminatedCloseEvent` class extending an `Error` for rejecting promises when terminating ([74b4ceb](74b4ceb)), closes [#531](#531)
* **server:** Dispose of subscriptions on close even if added late to the subscriptions list ([#534](#534)) ([e45d6b1](e45d6b1)), closes [#532](#532)

### Features

* **server:** Add is retry flag to connect events ([#507](#507)) ([9ad853f](9ad853f))
@enisdenjo
Copy link
Owner

🎉 This issue has been resolved in version 5.15.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released Has been released and published
Projects
None yet
2 participants