-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Make sure to clean context
during tearDownQuery
#7276
Conversation
0ba5abd
to
c079085
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dotansimha Although I hope we can prevent torn-down ObservableQuery
objects from remaining in memory unnecessarily, I agree this blunt approach seems like a worthwhile extra layer of defense.
c079085
to
42fdf44
Compare
@benjamn when an observable query is re-observed, it seems to come back to life (I don't know the exact details of this mechanism, but it's happening in my app). In this case however, the context has been deleted, so the query is incorrectly running without the originally specified context. I think this PR should be backed out. The context memory will be freed with the ObservableQuery is garbage collected. |
Thanks to @francisu for pushing back on the reasoning behind #7276: #7276 (comment) Thanks to #7661, we now have a system for programmatically testing garbage collection of discarded objects, so we can actually enforce the expectation that the whole ObservableQuery is garbage collected after the last subscriber is removed (which tears down the ObservableQuery and removes it from the QueryManager).
Hi @benjamn
This PR should ensure that even if
ObservableInfo
remains in memory, it won't hold a reference to user-objectcontext
after tear-down.The background is a memory-leak we are chasing in a large-scale app. I think the existence of the
context
reference in Apollo just makes it harder to detect, since it retaining it with no reason.I think even in a use-case of
subscribe
over awatchQuery
observable, withoutunsubscribing
reproduces that, since Apollo isn't removing theObservableQuery
while there are subscribers.