-
Notifications
You must be signed in to change notification settings - Fork 268
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
sdk: implement a sending queue #3465
Conversation
e1e0372
to
7ceace5
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3465 +/- ##
==========================================
+ Coverage 83.63% 83.72% +0.08%
==========================================
Files 254 255 +1
Lines 25592 25752 +160
==========================================
+ Hits 21405 21560 +155
- Misses 4187 4192 +5 ☔ View full report in Codecov by Sentry. |
bc4da6d
to
edf6867
Compare
Extracted some bits of this PR as #3475, as an attempt to make reviewing it easier. |
edf6867
to
dc0f2e8
Compare
…ground This implements the following features: - enabling/disabling the sending queue at a client-wide granularity, - one sending queue per room, that lives until the client is shutting down, - retrying sending an event three times, if it failed in the past, with some exponential backoff to attempt to re-send, - allowing to cancel sending an event we haven't sent yet. fixup sdk
A client would require this to know that the sending queue has been globally disabled, across all the rooms, otherwise they couldn't know that it needs to be re-enabled later on.
So as to not use sync mutexes across await points, we have to use an async mutex, BUT it can't be immediately called in a wiremock responder, so we need to shoe-horn a bit: create a new tokio runtime, which can only be called from another running thread, etc. It's a bit ugly, but I couldn't find another mechanism to block the responder from returning a Response immediately; happy to change that anytime if there's a simpler way.
dc0f2e8
to
ae66ef2
Compare
Thanks @Hywan for the review comments!
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.
After 1h15 in a pair-reviewing session, I approve this nice PR, well done!
Most of #3361, except for storing/reloading the local echoes from the disk.