fix(latest_event): handle edits when the target event is not directly preceding

[Johennes]

Problem: The latest event calculation currently only considers edits when the replacement event directly follows the replaced event with no other events in-between. This leads to incorrect latest event values in certain situations such as when an event is edited twice in a row.

This PR changes the calculation to remember the latest edit per event ID, continue iterating backwards until an actual matching event is found and then return that event's latest edit or the event itself if it hasn't been edited.

• Public API changes documented in changelogs (optional)

[codecov]

Codecov Report

❌ Patch coverage is 98.95833% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.86%. Comparing base (2f7887d) to head (a92ae5a).
⚠️ Report is 13 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...trix-sdk/src/latest_events/latest_event/builder.rs	98.95%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6096      +/-   ##
==========================================
+ Coverage   89.84%   89.86%   +0.02%     
==========================================
  Files         362      362              
  Lines      100433   100680     +247     
  Branches   100433   100680     +247     
==========================================
+ Hits        90230    90479     +249     
+ Misses       6678     6676       -2     
  Partials     3525     3525              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing Johennes:johannes/latest-event-edits (a92ae5a) with main (40c6c33)}

Summary

✅ 50 untouched benchmarks

[Hywan]

Thanks for the contribution.

Sorry if the documentation didn't convey this constraint correctly, but there is something important to know.

Why do we only support edits that apply to the immediately previous event? To avoid a situation where an edit of an old message would make the event to pop as a latest event. Imagine you've messages A, B, C.

• The latest event is C.
• Then, C is edited to D. The latest event must be D.
• Then, A is edited to X. You don't want X to be the latest event, you still want D to be The One.

Now. I understand the problem with a double edit. Sorry for having missed this… and thanks for tackling this problem.

But, we need to be very aware of the rule: an edit must be ignored if another event is inserted between the edit and the related event. And that's not what your code does as far as I understand it, right?

[Johennes]

But, we need to be very aware of the rule: an edit must be ignored if another event is inserted between the edit and the related event. And that's not what your code does as far as I understand it, right?

If I understood correctly, it should actually do just that. The new logic is to go backwards, remembering edits until you hit a target event. Then you return the latest edit of that event or the event itself if there are no edits.

In your example, the chain is: X (edits A) > D (edits C) > C > B > A

The code should skip over the two edits until it hits C and then take the latest edit for C which is D.

I've added a test case for it in a92ae5a.