-
Notifications
You must be signed in to change notification settings - Fork 81
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
rpc: fix subscribers locking logic and properly drain poll-based waiter receiver #2804
Conversation
Follow the other errors formatting style.
Make it more detailed for better debugging experience.
If it's a subscription for AERs, we need to check the filter's state only if it has been provided, otherwise filter is always valid.
b400770
to
72f8017
Compare
pkg/rpcclient/actor/waiter.go
Outdated
// We can easily end up in a situation when subscription was performed too late and | ||
// the desired transaction and VUB-th block have already got accepted before the | ||
// subscription happened. Thus, always retry with non-ws client, it will perform | ||
// AER requests and make sure. |
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.
Subscribe first, send afterwards? We need some issue for it.
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.
See #2805.
72f8017
to
d218c78
Compare
There still some deadlock either in |
Found it, we need to rework the logic of |
Do not block subscribers until the unsubscription request to RPC server is completed. Otherwise, another notification may be received from the RPC server which will block the unsubscription process. At the same time, fix event-based waiter. We must not block the receiver channel during unsubscription because there's a chance that subsequent event will be sent by the server. We need to read this event in order not to block the WSClient's readloop.
If VUB-th block is received, we still can't guaranty that transaction wasn't accepted to chain. Back this situation by rolling back to a poll-based waiter.
54336cf
to
3588ad5
Compare
Avoid receiver channels locks.
3588ad5
to
1399496
Compare
OK, it should work properly now, the test is also fixed. |
Codecov Report
@@ Coverage Diff @@
## master #2804 +/- ##
==========================================
+ Coverage 84.75% 84.77% +0.01%
==========================================
Files 327 327
Lines 41368 41390 +22
==========================================
+ Hits 35062 35088 +26
+ Misses 4876 4869 -7
- Partials 1430 1433 +3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
The main thing for now is that it fixes #2775. Waiter has a bit more chances now too.
Close #2775.
@roman-khimov, it's a bingo...