You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a dupe of #124, but everyone in that thread completely missed the root cause of the memory leak.
If using a for await loop, the return()/throw() methods of an AsyncIterator aren't going to get called unless iteration actually begins (by calling next()).
Because of this, calling subscribeAll in the PubSubAsyncIterator constructor is a memory leak. subscribeAll should instead be called in the first call to next(), because only then do you have a guarantee that consuming code is going to call return() or throw() to clean up the subscription.
graphql-subscriptions merged my PR to not subscribe until the first call to next() in their PubSubAsyncIterator implementation, so this is legit.
Here is a screenshot of our memory leaks in production related to this (you can see the PubSubAsyncIterator in the Retainers section):
The text was updated successfully, but these errors were encountered:
This is a dupe of #124, but everyone in that thread completely missed the root cause of the memory leak.
If using a
for await
loop, thereturn()
/throw()
methods of anAsyncIterator
aren't going to get called unless iteration actually begins (by callingnext()
).Because of this, calling
subscribeAll
in thePubSubAsyncIterator
constructor is a memory leak.subscribeAll
should instead be called in the first call tonext()
, because only then do you have a guarantee that consuming code is going to callreturn()
orthrow()
to clean up the subscription.graphql-subscriptions
merged my PR to not subscribe until the first call tonext()
in theirPubSubAsyncIterator
implementation, so this is legit.Here is a screenshot of our memory leaks in production related to this (you can see the
PubSubAsyncIterator
in the Retainers section):The text was updated successfully, but these errors were encountered: