-
Notifications
You must be signed in to change notification settings - Fork 170
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
client: add Subscription::close_reason
#1320
Conversation
…pi-v5' into na-improve-client-subscription-api-v5
…pi-v5' into na-improve-client-subscription-api-v5
Subscription::close_reason
mut sub: Subscription<T>, | ||
buffer_size: usize, | ||
) -> impl Stream<Item = Result<T, BroadcastStreamRecvError>> { | ||
let (tx, rx) = tokio::sync::broadcast::channel(buffer_size); |
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.
Ooh I didn't realise that this channel handled lagging messages, TIL :)
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.
Cool! Looks good 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.
LGTM! Nice one 👍
With this PR we should have a bit more info about what happens when the subscription stream ends, which makes our life easier when debugging connectivity issues 🙏
This PR changes adds a new API to the subscription know how the subscription was closed.
It still drops the subscription if it's lagging but the subscription should easily-extendable to
implement specific handling for lagging, see the example below
Example of custom subscription logic
Resolves #1291