fix: Ensure backfilled events cannot become forward extremities #2119
No reviewers
Labels
No labels
Abandoned
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
bob the builder
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!2119
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "eleboucher/continuwuity:fix/late-events-as-forward-extremities"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Events arriving after a child of theirs has already been backfilled are no longer installed as forward extremities. Backfilled events now mark their prev_events as referenced, and a backfilled event that nothing references can itself act as a forward extremity, so the branch it sits on stays reachable. Also corrected an inverted debug assertion in
get_missing_eventsthat made debug builds panic when an incoming event had none of its prev_events locally.Fixes: #2115
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
7e1c8e74aac1d0fbbe64fix: Do not make late-arriving events forward extremitiesto fix: Ensure backfilled events cannot become forward extremitiesc1d0fbbe64f98f4ea8d7@ -198,0 +202,4 @@.pdu_metadata.is_event_referenced(&incoming_pdu.room_id_or_hash(), incoming_pdu.event_id()).await;if !has_child || forward_extremities.is_empty() {I'm icky about this being possible in the first place, but i guess it's not a terrible idea to have a break-glass workaround
@ -216,0 +220,4 @@.mark_as_referenced(&room_id, pdu.prev_events().map(AsRef::as_ref));// If nothing references this event, it is a leaf, so it belongs in the forward// extremities.There's never a situation in which a backfilled event is legally supposed to become a forward extremity as far as I'm aware - the server only starts tracking extremities after it finishes joining a room, at which point the membership event is the only extremity it cares about. Other servers should deal with unreferenced forks post factum if said forks aren't already convened by the join event itself
Furthermore, we're expected to be able to serve state at for events we reference in prev events, which we cannot do for backfilled events yet (I'm working on this), so this might also potentially cause our subsequent events to be proactively dropped
f98f4ea8d7c96f22da3f@ -158,2 +157,3 @@} else {i} else {i.expected_add(1)idk anything about rust but these are usually saturating ? should this be expected ?
An expected add is fine because the value will never overflow (u8 can store up to 255, but there can only be 20 prev events, effectively clamping the max value at 20)
c96f22da3f5dc46bf7d75dc46bf7d70336850dc80336850dc83efb66c76c