server: Expose the subscription ID #900
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
niklasad1
reviewed
Oct 12, 2022
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
niklasad1
approved these changes
Oct 12, 2022
jsdw
approved these changes
Oct 13, 2022
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The subscription ID on the server side is required by the new RPC Spec,
specifically by the archive class of methods.
The subscription ID generated from the chainHead_unstable_follow is passed to
the other archive methods (ie chainHead_unstable_body). The server needs to
keep track of this ID for validity purposes.
This PR exposes the subscription ID via the
SubscriptionSink::accept.The
acceptmethod marks the point of sending the ID to the client.Although the subscription ID exists on the server side prior to this call,
this information is unusable if it cannot be propagated to the client.
This adds a change to the main
SubscriptionSinkAPI without breakingthe current behavior of
SubscriptionSink::pipe_from_stream.If the server is interested in the subscription ID, it can simply call the
acceptprior topipe_from_stream.This is part of the paritytech/substrate#12071.