-
Notifications
You must be signed in to change notification settings - Fork 324
feat(sdk): Introduce the new LatestEvents
API, part 3: Computing from the Send Queue
#5482
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
base: main
Are you sure you want to change the base?
Conversation
f3d6c35
to
b66b454
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #5482 +/- ##
==========================================
+ Coverage 88.57% 88.62% +0.04%
==========================================
Files 340 340
Lines 93743 94891 +1148
Branches 93743 94891 +1148
==========================================
+ Hits 83036 84097 +1061
- Misses 6575 6617 +42
- Partials 4132 4177 +45 ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #5482 will not alter performanceComparing Summary
|
8f06956
to
a554133
Compare
…dates_task`. This patch removes the intermediate `rooms` variable in a new block. The read-lock can be used immediately.
This patch updates `LatestEvents` to listen to the updates from the `SendQueue`. The `listen_to_event_cache_and_send_queue_updates` function contains the important change. A new `LatestEventQueueUpdate` enum is added to represent either an update from the event cache, or from the send queue. So far, `compute_latest_events` does nothing in particular, apart from panicking with a `todo!()` when a send queue update is met.
…vents`. This patch renames the `update` methods to `update_with_event_cache` in the `latest_events` module. It frees the road to introduce `update_with_send_queue`.
…ent`. This patch updates `compute_latest_events` to broadcast a `RoomSendQueueUpdate` onto `LatestEvent`. It introduces the new `update_with_send_queue` method.
This patch splits the `LatestEventValue` type into `LatestEventValue` + `LatestEventKind`. Basically, all variants in `LatestEventValue` are moved inside the new `LatestEventKind` enum. `LatestEventValue` keeps `None`, and see the new `Remote`, `LocalIsSending` and `LocalIsWedged` variants. This patch also extracts the message-like handling of `find_and_map` (now renamed `find_and_map_timeline_event`) into its own function: `find_and_map_any_message_like_event_content`. This is going to be handful for the send queue part.
This patch implements `LatestEvent::update_with_send_queue`. It introduces an intermediate type, for the sake of clarity, `LatestEventValuesForLocalEvents`. The difficulty here is to keep a buffer of `LatestEventValue`s requested by the `SendQueue`. Why? Because we want the latest event value, but we only receive `RoomSendQueueUpdate`s, we can't iterate over local events in the `SendQueue` like we do for the `EventCache` to re-compute the latest event if a local event has been cancelled or updated. A particular care must also be applied when a local event is wedged: this local event and all its followings must be marked as wedged too, so that the `LatestEventValue` is `LocalIsWedged`. Same when the local event is unwedged.
8b7aef0
to
15843a0
Compare
This patch introduces `LatestEventKind::Redacted` to handle the case where an event is supposed to be a latest event but has been redacted.
15843a0
to
63ae70c
Compare
This patch adds a new feature to
LatestEvents
: it now listens to theSendQueue
!Most of the addition are related to tests. I've tried to keep the commits are small and atomic as possible. We follow and update the code gradually.
LatestEventValuesForLocalEvents
A new type is introduced to manage a buffer of
LatestEventValue
for local events:LatestEventValuesForLocalEvents
. A bit of explanations.The system does only receive
RoomSendQueueUpdate
s. It's not designed to iterate over local events in the send queue when a local event is changed (cancelled, or updated for example). That's why we keep our own buffer here. Imagine the system receives 4RoomSendQueueUpdate
:RoomSendQueueUpdate::NewLocalEvent
: new local event,RoomSendQueueUpdate::NewLocalEvent
: new local event,RoomSendQueueUpdate::ReplacedLocalEvent
: replaced the first local event,RoomSendQueueUpdate::CancelledLocalEvent
: cancelled the second local event.NewLocalEvent
s will trigger the computation of newLatestEventValue
s, butCancelledLocalEvent
for example doesn't hold any information to compute a newLatestEventValue
, so we need to remember the previous values, until the local events are sent and removed from this buffer.Another reason why we need a buffer is to handle wedged local event. Imagine the system receives 3
RoomSendQueueUpdate
:RoomSendQueueUpdate::NewLocalEvent
: new local event,RoomSendQueueUpdate::NewLocalEvent
: new local event,RoomSendQueueUpdate::SendError
: the first local event has failed to be sent.Because a
SendError
is received (targeting the firstNewLocalEvent
), the send queue is stopped. However, theLatestEventValue
targets the secondNewLocalEvent
. The system must consider that when a local event is wedged, all the following local events must also be marked as wedged. And vice versa, when the send queue is able to send an event again, all the following local events must be marked as unwedged.This type isolates a couple of methods designed to manage these specific behaviours.
LatestEvents API
, part 2: Computing from the Event Cache #5340