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

Fix cleanup observer blocking unsubscribe (2) (#6985) #7170

Conversation

javier-garcia-meteologica
Copy link
Contributor

This patch decrements the addCount tally so this.sub can be unsubscribed and queries are aborted.

Checklist:

  • If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
  • Make sure all of the significant new logic is covered by tests

@apollo-cla
Copy link

@javier-garcia-meteologica: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

@dotansimha
Copy link
Contributor

dotansimha commented Oct 15, 2020

This is great! Really waiting for this to get merged. We noticed another issue we are investigating now, seems like it's related to GraphQL subscriptions. We see some weak references that retain in memory. It might be addressed by this as well.

The test failure in apollographql#7170 was a case of unsubscribing the last observer
and then immediately resubscribing another observer, which should keep the
subscription alive, for backwards compatibility. Delaying the unsubscribe
to a later microtask tick enables this use case, while still unsubscribing
very soon after the last non-cleanup Concast observer unsubscribes.

In case there are still any cleanup observers in this.observers, and no
error or completion has been broadcast yet, we call this.handlers.error to
make sure those cleanup observers receive an error that terminates them.
@benjamn
Copy link
Member

benjamn commented Oct 15, 2020

@javier-garcia-meteologica Thanks for adding a test!

I was able to fix the test failure by adding a Promise.resolve().then delay to the sub.unsubscribe() call, which seems important for backwards compatibility (so unsubscribing the last observer and then immediately subscribing another observer does not terminate the underlying subscription).

I also noticed that we were not always terminating cleanup observers if there are any left in this.observers when the last non-cleanup observer is removed by removeObserver, so now that's handled better.

@benjamn benjamn added this to the Post 3.0 milestone Oct 15, 2020
Copy link
Member

@benjamn benjamn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@javier-garcia-meteologica I think this is close, but I'd like to see if we can avoid the changes to MockLink (see #7170 (comment)). What do you think?

Copy link
Member

@benjamn benjamn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@javier-garcia-meteologica Perfect, thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants