-
Notifications
You must be signed in to change notification settings - Fork 358
fix(ui): Sending read receipt in live timeline uses threaded event id instead #5864
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
Conversation
CodSpeed Performance ReportMerging #5864 will not alter performanceComparing Summary
Footnotes |
07141d7 to
ef9278f
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5864 +/- ##
=======================================
Coverage 88.59% 88.59%
=======================================
Files 363 363
Lines 102888 102926 +38
Branches 102888 102926 +38
=======================================
+ Hits 91153 91188 +35
- Misses 7496 7498 +2
- Partials 4239 4240 +1 ☔ View full report in Codecov by Sentry. |
…n a thread Previously, this used the latest event in the thread as the event to mark as read, while this is not right if we're in a context that hides thread events
ef9278f to
635313a
Compare
…ne::latest_event_id`, instead of `ui::Timeline::latest_event` This is important because `latest_event` would also return local events, which won't have an event id.
Hywan
left a comment
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.
Looks good to me, modulo the small feedback. Thank you for the new test and for the fix!
| /// remote event, but if it moves, it has an impact on this mapping. | ||
| pub timeline_item_index: Option<usize>, | ||
|
|
||
| pub thread_root_id: Option<OwnedEventId>, |
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.
Please add documentation for this field. Also —just a personal taste— I would put this field after event_id, not mandatory.
| .iter() | ||
| .rev() | ||
| .filter_map(|item| { | ||
| if !filter_out_thread_events || item.thread_root_id.is_none() { |
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.
Can you explain with an inline comment here why we want to filter out event with a thread root?
| } | ||
| } | ||
|
|
||
| /// Get the latest of the timeline's event ids. |
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.
You may want to precise that, contrary to latest_event, this method only returns the ID of the last remote event (which is obvious for us because a local event doesn't have an event ID, only a transaction ID, but it's better to make it clear.
Also move `EventMeta::thread_root_id` next to `event_id`
Changes:
hide_thread_eventsis enabled.EventMetahas now athread_root_idfield so we can know if the event is part of a thread, andTimelineController::latest_event_idfilters those out ifhide_thread_eventsis enabled.visibleitems? Because reactions, edits, replacements, etc. are also non-visible items that have to be taken into account for the read receipts. So it seems like we have 2 types of 'not visible' items in the timeline, those that aren't visible because we don't want to display them as separate items (aggregations), and those that aren't visible because they shouldn't be displayed at all.hide_threaded_events, so some tests were broken.main- not really related to this PR, but it also made it fail in CI. It looks like a race condition of some kind.ffi::Timeline::latest_event_idto useui::Timeline::latest_event_id, which will return the value fromTimelineController::latest_event_id.Fixes element-hq/element-x-android#5639.
Signed-off-by: