-
Notifications
You must be signed in to change notification settings - Fork 269
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
Retry decryption from a long-lived async task, instead of lots of detached ones #4715
base: main
Are you sure you want to change the base?
Conversation
…el, instead of spawning a task directly
…nto the async task
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4715 +/- ##
==========================================
- Coverage 85.94% 85.93% -0.02%
==========================================
Files 290 291 +1
Lines 33839 33856 +17
==========================================
+ Hits 29084 29093 +9
- Misses 4755 4763 +8 ☔ View full report in Codecov by Sentry. |
This lines that codecov is complaining about missing coverage are pretty much all lifted-and-shifted from the their old location into |
Part of element-hq/element-meta#2697
In response to a comment on #4644 - avoid spawning a detached async task every time we have some things to decrypt because some Megolm sessions updated.
I strongly suggest reviewing commit by commit, since this is structured as a set of refactorings that hopefully make sense individually.
Instead, we create one async task and hold it inside a new struct called
RetryDecryptionTask
. This struct holds one end of channel, and sends retry requests to the async task, which stops when the channel is closed, which will happen when theRetryDecryptionTask
struct is dropped.So we keep the feature that retrying decryption does not block the main processing, but we lose the spawning of lots of async tasks that are not kept track of.
As written, the task is not cancellable, but this could be added if we think we need it.