fix: Properly track orphaned extremities #2164
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
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!2164
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "nex/fix/extremity-tracking-please-please-please-im-so-sick-of-fixing-extremity-tracking"
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?
This pull request fixes extremity tracking once again, this time fixing the issue where soft-failed/rejected events fail to adequately mark their predecessors as referenced, which resulted in a build-up of orphaned extremities. This PR solves that by reworking how extremities are calculated to use this new algorithm:
prev_events:i. Mark the ancestor as referenced and drop it from the extremity set
ii. Gather all
prev_eventsof the ancestor that are soft-failed OR rejected OR an outlier for another reason, AND not yet marked as referencediii. Add each ancestor from the previous step to the queue
iv. Repeat until there are no more such events from step ii
this ensures events which have actually been referenced but perhaps only by an event which was not added to our timeline tree is appropriately marked as such, preventing a build-up of soft-failed and rejected events.
Fixes: #2123
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
Uh are rejected events supposed to mark things as referenced? I don't think they are given they are excluded from the DAG
@ -221,1 +250,4 @@if forward_extremities.is_empty() {return Err!("Resolved extremities cannot be empty");}Ok(forward_extremities)i guess we should return new_extremities there
@ -191,3 +192,2 @@.await.eq(&false).then_some(event_id).then_some(extremity)i guess this is not what we want, this keeps the referenced events and drops the unreferenced ones. Needs the .eq(&false) back
@ -213,0 +223,4 @@.map(ToOwned::to_owned).stream().broad_filter_map(|prev_id| async move {let room_id = incoming_pdu.room_id_or_hash();we have it already on 210
Already have what? 210 is the incoming event's
prev_events(initial work set), this line adds any prev events of the prev event we're working on that is unreferenced and a local outlier/soft-failed/rejected, so that their prev events will be walked until we reach the root of the unaccepted tree and reach the first accepted event (or create event)we already have the room_id we don't need to create it again no ?
Oh yeah, so we do, I forgot I put that up there
@nex fix
She just want to eat our memory like a cookie monster
Sorry this wasn't quite ready for review, I had changed staged but couldn't push them as the forge went down
@Jade wrote in #2164 (comment):
They aren't marking things as referenced, this is only if they're ancestors of a legal event (or an event referenced by the ancestor that previously would've been unreferenced). Synapse also does this
@ -180,0 +182,4 @@current_extremities.into_iter().collect();// Add the incoming eventnew_extremities.insert(incoming_pdu.event_id().to_owned());// Remove any extremities that have since been referenced but not removed(?)that "(?)" fills me with confidence
I don't think it's possible but it's a good check to have anyway to be safe, no?
@ -219,3 +250,2 @@);assert!(!forward_extremities.is_empty(), "resolved extremities cannot be empty");Ok(forward_extremities)debug_assert!(!new_extremities.is_empty(), "resolved extremities cannot be empty");me when I check the same thing twice
In debug this will panic (incredibly noisy), in release this will simply return an error (still noisy but unlikely to Fuck Shit Up)
this could be one
ifwith a#[cfg(debug_assertions)] { panic!() }but ok 🤓I could do this but my IDE insists that Err!() is unreachable because it lints with the debug profile 😭
I could make a new
debug_assert_or_errormacro 🤔it is unreachable because that
panic!doesn't have a#[cfg]on iteven with the cfg, I apologise for writing code in the forgejo comment box it wont happen again
add a
#[cfg(not())]on the err return thenBut then I'd be writing
which is insane, and the current
is just better atp
no it's much clearer
6a58539caf103dafd529