-
-
Notifications
You must be signed in to change notification settings - Fork 163
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
Comments
Wow great catch! I've managed to create a failing test replicating what you've described. Thanks for reporting it! Fix coming soon. |
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))
🎉 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
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.graphql-ws/src/server.ts
Line 797 in e2603be
Once the returned promise is resolved a subscription entry is made in
ctx.subscriptions
.graphql-ws/src/server.ts
Line 812 in e2603be
If the promise is resolved after the websocket close handler has been called the an entry is still made in
ctx.subscriptions
and itsreturn
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 byyarn start
and open a browser window for http://localhost:4000/graphql. Start a subscription in that window :--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
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.
The text was updated successfully, but these errors were encountered: