Add an extra ergonomic method for n2c chainsync #439
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
When actually consuming the chainsync client, initially the consumer should call request_next repeatedly. However, once you are caught up, you will get an "Await" response, which says we've requested the next block, but the server doesn't have one for us, and will let us know when one is available. If we request_next again, it fails. In fact, even the example was misleading in this way! The correct way to consume it was to check if you have agency, and if so, either await or recieve. If you tried to do this, though, especially when mixing it with other future things (like select! on a cancellation token), then things could get messy, because even though they return the same type, the impl Future instances were opaque to the compiler. This convenience method makes it nice and simple to idiomatically just consume the next block as appropriate, and plays well with select!
Quantumplation
force-pushed
the
pi/ergonomic-chainsync
branch
from
8b3fb45
to
df2c4c0
Compare
Rebased, and this type has been updated since
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.
When actually consuming the chainsync client, initially the consumer
should call request_next repeatedly. However, once you are caught up,
you will get an "Await" response, which says we've requested the next
block, but the server doesn't have one for us, and will let us know when
one is available. If we request_next again, it fails.
In fact, even the example was misleading in this way!
The correct way to consume it was to check if you have agency, and if
so, either await or recieve.
If you tried to do this, though, especially when mixing it with other
future things (like select! on a cancellation token), then things could
get messy, because even though they return the same type, the impl
Future instances were opaque to the compiler.
This convenience method makes it nice and simple to idiomatically just
consume the next block as appropriate, and plays well with select!