This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When an rpc client connects to a node, it subscribes to a few keys to receive update when they change. Internally that is offloaded to
client.notification_stream
, which holds the actual logic to figure out if it matches and trigger an event on anunbounded
channel if it does.When the RPC disconnects all these subscriptions are discarded, the Receivers drop, which would mean the notification stream will also drop them on the next trigger that matches them – eventually cleaning it up internally.
Well, that's the theory. But because it only checks for the dropped ones whenever they match, rarely (or effectively never) changing keys are not included in the check. And one of those rarely changing keys is one the Polkadot JS App is very interested in: the runtime version. Thus, whenever a client connects via rpc and subscribes to that (which it does at start up), it is added to the stream notifications, yet effectively never removed. Leading to us accumulating stale sinks that are never cleaned up.
This PR fixes this leak by iterating through all sinks on every
trigger
and remove those that not connected anymore. Thus we clean this upon effectively evertrigger
cycle.Note: A cleaner way to resolve this issue would be to hand over the subscriber ID to the outside of stream notifications and provide an API to actively remove subcribers rather than relying on the implic drop to take place. So that the RPC could do that right on the connection drop (as it does for its own internal subscription system). But that is a more involved change that we don't want to do at the moment.
Todo: