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.
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
feat(rpc module):
stream API
for SubscriptionSink #639feat(rpc module):
stream API
for SubscriptionSink #639Changes from 4 commits
72024ea
fe176df
eebc73d
a29f988
6aa22e2
9bdea0d
79a8e55
7e81acf
6982598
d589d24
92bb97e
b9598ca
bce48da
6d16927
a47a965
07f80e2
bedf808
03ef669
ef7b965
f7aa544
72f4726
7a20a52
de4ac6a
fa15cfb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
NOTE: this panics if count > usize::MAX / 2
but if we reach that we likely have other problems such as OOM :)
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.
If it bust be
Some
, why don't we restrict it on parameter level?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.
it's way better but I think it requires additional callback types right? see my comment below.
thoughts?
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.
Ok, I had a look at the code to solve this properly at
parameter level
one need to lookup at the actual callback to avoid to pass down a bunch of unused parameters.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.
one benefit is not to have to clone this "introduced channel connection_state" for every method instead only for subscriptions where it's actually used... not sure I liked how the old code abstracted this away
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.
I already thought about splitting async calls from subscriptions when doing my refactoring earlier, and for regular method calls returning values instead of passing in the sink as a parameter, I reckon that would make things much more readable and straight forward, and potentially make the final binary smaller. So if you want to go that route and add another enum variant I think that's cool, and I can do a PR that switches method calls to have a return value later on :).
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.
ah, I already added the enum variant in this PR but just a hacky draft to check that it works and to show you and David what I had in mind :)
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.
sounds great to get rid of the sink for the synchronous calls.
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.
What do you think about calling this
into_stream
? I think "add" implies there could be more than one and that it doesn't quite relay the information about the important changes that this call makes to the sink.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.
I don't like
add_stream
either, butinto_stream
is not really great either it doesn't return the stream....maybe
run_stream
,from_stream
,spawn_stream
or something else?!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.
Fair; I'd have liked
as_stream
butas_
is "taken" with different semantics so can't do that.Of your suggestions I like
from_stream
the best.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.
So, this method consumes a stream, feeding the items into the subscription?
I guess I'd go with something like
consume_stream
orread_from_stream
.into_
,as_
, andfrom_
all sortof feel like I should expect some result back from this call to me!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.
yes
I guess we could return a type that impls
Sink/SinkExt
instead here to make it more readable and flexible i.e, to deal with errors and so on.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.
streamify()
?I think
consume_stream
is so-so. Yes, we do consume it, but that's not really the point. Rather we're "hooking up" the stream to the sink and leave it there for the duration of the subscription.with_stream
?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.
pipe
, maybe? we're piping a stream into the subscription.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.
sink.pipe_from_stream
? I quite likepipe
!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.
I like
pipe_from_stream
, let's settle for that?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.
I felt like I understood the test until I got here. I thought
rx
would produceNone
after the client was dropped and so it'd beassert!(rx.next().await.is_none())
. What am I missing? :/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.
haha, maybe it's more clear as you described it but the test actually sends a message on the channel when the subscription terminated.
the reason why is because the
tx
is kept in the RpcModule and can't be dropped in the subscribe callback.