feat: PDU handler refresh #1944
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.
Blocks
#1952 feat: Improve inbound federated membership handling
continuwuation/continuwuity
Reference
continuwuation/continuwuity!1944
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "nex/fix/pdu-handler-refresh"
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 layers a fresh coat of paint over the federation PDU handler. This is primarily intended to improve maintainability and reusability (monolithic functions have been broken down into several smaller, more easily digestible functions), but also fixes a few bugs along the way, such as ACLs being applied too aggressively.
This is part of a series of changes I'm planning to make to how PDU lifetimes are handled, from creation to persistence. To keep PR sizes reviewable, each "milestone" will get a new PR sequentially.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
state_before_incomingb90ceee9f0build_local_dagto remove refmap hacksfeat: PDU handler refershto WIP: feat: PDU handler refershMarking as WIP until this has been tested
WIP: feat: PDU handler refershto WIP: feat: PDU handler refreshWIP: feat: PDU handler refreshto feat: PDU handler refresh@ -87,9 +87,7 @@ impl super::Service {let to_persist = if mapped.len() <= 1 {mapped.keys().map(ToOwned::to_owned).collect()seems to me like this check for an empty/one-item map should be part of build_local_dag
@ -128,2 +68,2 @@if !meta_exists {if !room_exists && !is_interesting_member_event {if is_interesting_member_event {what's going on with the logic here? this
ifcan only run ifis_interesting_member_event && !is_interesting_member_eventthat is a good question
@ -155,2 +98,3 @@// 8. if not timeline event: stop// If this is not a timeline event, stop now, as we don't want to de-outlier it.if !is_timeline_event {debug!("Not promoting incoming event as it is not a timeline event");"timeline event" is a really unhelpful name for this, that parameter would better be called
is_backfilled_event(which would also invert its meaning). honestly the fact that this early return exists at all suggests that this function should be split into two functionsThat would make more sense actually, it looks like the only time this condition is met is in backfill.rs
@ -171,3 +116,2 @@// 9. Fetch any missing prev events doing all checks listed here starting at 1.// These are timeline events// Fetch any missing prev events doing all checks listed here starting at 1.those checks are gone from the docstring so this comment is confusing now
@ -33,2 +47,3 @@if !Self::pdu_format_check_1(&value) {warn!("dropping incoming PDU {event_id} in room {room_id} from {origin} because it \"Dropping incoming PDU {event_id} in room {room_id} from {origin} because it \this warn should say "does not follow room version rules"
@ -382,2 +216,3 @@if soft_fail {if should_soft_fail {self.servicesThis can probably be done in
append_incoming_pdu, which returns early if the event is soft failedparse_incoming_pdu_with_known_room367a747344pdu_format_check_1@ -297,11 +297,7 @@ async fn handle_room(// failure (e.g., cycles). This is best-effort; proper ordering is the sender's// responsibility.let sorted_event_ids = if pdu_map.len() >= 2 {this if should no longer be needed
@ -385,3 +173,2 @@.mark_event_soft_failed(incoming_pdu.event_id());info!(if should_soft_fail {could this log be moved into
append_incoming_pdu?It could, but then there'd be eight parameters on the function, one of those just being an
Instant. I don't think it's worth it, there's already too many params985b45d0389d2ce72f73