refactor: standardize event handling in federation-matrix

[ggazzo]

https://rocketchat.atlassian.net/browse/FB-58
Updated event handlers in member, message, reaction, and room modules to use destructured event objects for improved readability and consistency. This change enhances the clarity of the code by directly accessing event properties, reducing the need for repetitive data extraction.

Proposed changes (including videos or screenshots)

Issue(s)

Steps to test or reproduce

Further comments

Summary by CodeRabbit

• Refactor
  • Standardized event handling patterns across federation matrix services to enhance code maintainability and consistency without affecting end-user functionality.

[dionisio-bot]

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

[changeset-bot]

⚠️ No Changeset found

Latest commit: 031911c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

The PR standardizes event payload access patterns across federation-matrix event handlers by refactoring handlers to destructure and access event objects consistently. Instead of receiving raw wrapper data, handlers now directly read from nested event payloads, replacing all data.* references with event.* across member, message, reaction, and room event handlers.

Changes

Cohort / File(s)

Change Summary

Event Handler Refactoring ee/packages/federation-matrix/src/events/member.ts, ee/packages/federation-matrix/src/events/message.ts, ee/packages/federation-matrix/src/events/reaction.ts, ee/packages/federation-matrix/src/events/room.ts

Updated all event handlers to destructure event payloads and access properties via event.* instead of data.*. Function parameters changed from raw data objects to destructured event objects (e.g., membershipLeaveAction and membershipJoinAction now accept event: HomeserverEventSignatures['homeserver.matrix.membership']['event']). Updated error/warn/log messages, null checks, and all downstream logic to reference the new event structure. Reaction handler also extracts event_id separately. Room handler reads topic from event.content.topic and userId from event.sender.

Sequence Diagram

sequenceDiagram
    participant Emitter
    participant Handler
    participant Logic

    rect rgb(200, 220, 240)
    Note over Emitter,Handler: Before Refactoring
    Emitter->>Handler: emit(event, {event: {...}, data: {...}})
    Handler->>Handler: data = payload<br/>access via data.event.sender
    Handler->>Logic: process(data.event.*)
    end

    rect rgb(220, 240, 200)
    Note over Emitter,Handler: After Refactoring
    Emitter->>Handler: emit(event, {event: {...}})
    Handler->>Handler: destructure { event }<br/>access via event.sender
    Handler->>Logic: process(event.*)
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Areas requiring attention:
  • Verify all data.* references were correctly converted to event.* across all four files
  • Confirm property path correctness (e.g., event.sender, event.content.topic, event.state_key) matches the new destructured event shape
  • Check that destructured parameter names in emitter handlers ({ event }, { event, event_id }) align with the emitter payload structure

Possibly related PRs

• fix: process joins from full state #37156: Adds emitJoin which emits homeserver.matrix.membership events with the event field that this PR now expects handlers to receive.
• regression(federation): Old federation users #37102: Modifies the same member.ts membership handlers, altering how they resolve usernames and create federated users.
• fix(federation): unset reactions not working from remote #37121: Refactors reaction.ts redaction and reaction handling to access nested event payloads consistently.

Suggested reviewers

• ggazzo
• sampaiodiego
• rodrigok

Poem

🐰 Events now flow with unified grace,
No nested wrappers cluttering the space,
From data.data to direct event streams,
Four handlers aligned—a refactorer's dreams!
Consistency blooms where chaos once grew. ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'refactor: standardize event handling in federation-matrix' accurately describes the main change: updating event handlers to use destructured event objects for consistency.
Linked Issues check	✅ Passed	The pull request addresses the primary objective of FB-58 by standardizing event handling across multiple federation-matrix modules (member, message, reaction, room).
Out of Scope Changes check	✅ Passed	All changes are focused on standardizing event handling patterns in federation-matrix event handlers; no unrelated modifications detected.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/federation-emit

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ed544f8 and 031911c.

📒 Files selected for processing (4)

• ee/packages/federation-matrix/src/events/member.ts (3 hunks)
• ee/packages/federation-matrix/src/events/message.ts (13 hunks)
• ee/packages/federation-matrix/src/events/reaction.ts (3 hunks)
• ee/packages/federation-matrix/src/events/room.ts (1 hunks)

🧰 Additional context used

🧠 Learnings (4)

📓 Common learnings

Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 37205
File: ee/packages/federation-matrix/src/FederationMatrix.ts:296-301
Timestamp: 2025-10-28T16:53:42.761Z
Learning: In the Rocket.Chat federation-matrix integration (ee/packages/federation-matrix/), the createRoom method from rocket.chat/federation-sdk will support a 4-argument signature (userId, roomName, visibility, displayName) in newer versions. Code using this 4-argument call is forward-compatible with planned library updates and should not be flagged as an error.

Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 37205
File: ee/packages/federation-matrix/src/FederationMatrix.ts:296-301
Timestamp: 2025-10-28T16:53:42.761Z
Learning: In the Rocket.Chat federation-matrix integration (ee/packages/federation-matrix/), the createRoom method from rocket.chat/federation-sdk will support a 4-argument signature (userId, roomName, visibility, displayName) in newer versions. Code using this 4-argument call is forward-compatible with planned library updates and should not be flagged as an error.

Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 37377
File: apps/meteor/ee/server/hooks/federation/index.ts:86-88
Timestamp: 2025-11-04T16:49:19.107Z
Learning: In Rocket.Chat's federation system (apps/meteor/ee/server/hooks/federation/), permission checks follow two distinct patterns: (1) User-initiated federation actions (creating rooms, adding users to federated rooms, joining from invites) should throw MeteorError to inform users they lack 'access-federation' permission. (2) Remote server-initiated federation events should silently skip/ignore when users lack permission. The beforeAddUserToRoom hook only executes for local user-initiated actions, so throwing an error there is correct. Remote federation events are handled separately by the federation Matrix package with silent skipping logic.

📚 Learning: 2025-10-28T16:53:42.761Z

Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 37205
File: ee/packages/federation-matrix/src/FederationMatrix.ts:296-301
Timestamp: 2025-10-28T16:53:42.761Z
Learning: In the Rocket.Chat federation-matrix integration (ee/packages/federation-matrix/), the createRoom method from rocket.chat/federation-sdk will support a 4-argument signature (userId, roomName, visibility, displayName) in newer versions. Code using this 4-argument call is forward-compatible with planned library updates and should not be flagged as an error.

Applied to files:

• ee/packages/federation-matrix/src/events/room.ts
• ee/packages/federation-matrix/src/events/message.ts
• ee/packages/federation-matrix/src/events/member.ts

📚 Learning: 2025-11-04T16:49:19.107Z

Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 37377
File: apps/meteor/ee/server/hooks/federation/index.ts:86-88
Timestamp: 2025-11-04T16:49:19.107Z
Learning: In Rocket.Chat's federation system (apps/meteor/ee/server/hooks/federation/), permission checks follow two distinct patterns: (1) User-initiated federation actions (creating rooms, adding users to federated rooms, joining from invites) should throw MeteorError to inform users they lack 'access-federation' permission. (2) Remote server-initiated federation events should silently skip/ignore when users lack permission. The beforeAddUserToRoom hook only executes for local user-initiated actions, so throwing an error there is correct. Remote federation events are handled separately by the federation Matrix package with silent skipping logic.

Applied to files:

• ee/packages/federation-matrix/src/events/message.ts
• ee/packages/federation-matrix/src/events/member.ts

📚 Learning: 2025-09-19T15:15:04.642Z

Learnt from: rodrigok
Repo: RocketChat/Rocket.Chat PR: 36991
File: apps/meteor/server/services/federation/infrastructure/rocket-chat/adapters/Settings.ts:219-221
Timestamp: 2025-09-19T15:15:04.642Z
Learning: The Federation_Matrix_homeserver_domain setting in apps/meteor/server/services/federation/infrastructure/rocket-chat/adapters/Settings.ts is part of the old federation system and is being deprecated/removed, so configuration issues with this setting should not be flagged for improvement.

Applied to files:

• ee/packages/federation-matrix/src/events/member.ts

🧬 Code graph analysis (2)

ee/packages/federation-matrix/src/events/message.ts (3)

ee/packages/federation-matrix/src/events/room.ts (1)

• room (8-84)

ee/packages/federation-matrix/src/FederationMatrix.ts (1)

• fileTypes (21-26)

ee/packages/federation-matrix/src/helpers/message.parsers.ts (1)

• toInternalMessageFormat (109-119)

ee/packages/federation-matrix/src/events/member.ts (2)

ee/packages/federation-matrix/src/events/room.ts (1)

• room (8-84)

ee/packages/federation-matrix/src/FederationMatrix.ts (1)

• getUsernameServername (73-85)

🔇 Additional comments (9)

ee/packages/federation-matrix/src/events/reaction.ts (2)

11-48: LGTM! Clean refactoring to destructured event pattern.

The reaction handler has been successfully updated to use the new destructured event payload pattern. All references to data.sender, data.content, and data.event_id have been correctly replaced with event.sender, event.content, and the destructured eventId parameter. The logic and error handling remain intact.

---

50-92: LGTM! Redaction handler correctly updated.

The redaction handler follows the same consistent pattern, accessing event.redacts and event.sender from the destructured event object. The refactoring maintains the original functionality while improving consistency.

ee/packages/federation-matrix/src/events/message.ts (3)

122-272: LGTM! Comprehensive refactoring of message handler.

The message handler has been thoroughly updated to use the destructured { event, event_id: eventId } pattern. All property accesses have been correctly migrated from data.* to event.*, including complex nested properties like event.content.formatted_body, event.content['m.relates_to'], and event.content.url. The refactoring preserves all business logic including thread handling, quote messages, media attachments, and message editing.

---

274-386: LGTM! Encrypted message handler correctly refactored.

The encrypted message handler follows the same consistent pattern, properly accessing encrypted content via event.content.algorithm and event.content.ciphertext. The complex logic for handling encrypted message updates, threads, and quotes is preserved.

---

388-418: LGTM! Message redaction handler updated consistently.

The redaction handler properly accesses event.redacts and event.sender from the destructured event object, maintaining consistency with the redaction handler in reaction.ts.

ee/packages/federation-matrix/src/events/member.ts (3)

11-46: LGTM! Well-typed leave action refactoring.

The membershipLeaveAction function has been properly updated with an explicit type signature using HomeserverEventSignatures['homeserver.matrix.membership']['event']. All property accesses have been migrated from data.* to event.*, including the logic for distinguishing between voluntary leave and kick events using event.sender === event.state_key.

---

48-86: LGTM! Join action correctly refactored.

The membershipJoinAction function properly uses the event parameter structure, accessing event.room_id, event.sender, event.state_key, and event.content.displayname. The logic for handling both local and federated users is preserved.

---

88-104: LGTM! Membership event handler updated consistently.

The main event handler uses the destructured { event } pattern and routes to the appropriate action functions based on event.content.membership. This is consistent with the refactoring pattern applied across all federation-matrix event handlers.

ee/packages/federation-matrix/src/events/room.ts (1)

9-23: Refactor handlers to match established event pattern, but verify payload structure with federation-sdk v0.3.0.

The review comment correctly identifies a real inconsistency. All other event handlers (message, membership, reaction, topic) use the async ({ event, ... }) pattern, but the homeserver.matrix.room.name and homeserver.matrix.room.role handlers use a flat async (data) pattern. This inconsistency should be resolved.

However, the exact field mappings suggested in the diffs require verification against the federation-sdk v0.3.0 type definitions for HomeserverEventSignatures['homeserver.matrix.room.name'] and HomeserverEventSignatures['homeserver.matrix.room.role']. The suggested fields (content: { name }, state_key, sender) align with Matrix event structure patterns visible in the topic handler, but cannot be confirmed without access to the federation-sdk type definitions.

Update both handlers to follow the established async ({ event }) pattern used throughout the codebase, and verify the field names match what federation-sdk v0.3.0 provides for these specific event types.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example:

"Create a concise high-level summary as a bullet-point list. Then include a Markdown table showing lines added and removed by each contributing author."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

📦 Docker Image Size Report

📈 Changes

Service	Current	Baseline	Change	Percent
sum of all images	1.2GiB	1.2GiB	+12MiB
rocketchat	367MiB	355MiB	+12MiB
omnichannel-transcript-service	141MiB	141MiB	-1.3KiB
queue-worker-service	141MiB	141MiB	-441B
ddp-streamer-service	127MiB	127MiB	-687B
account-service	114MiB	114MiB	+179B
stream-hub-service	111MiB	111MiB	-930B
authorization-service	111MiB	111MiB	-289B
presence-service	111MiB	111MiB	+1.6KiB

📊 Historical Trend

---
config:
  theme: "dark"
  xyChart:
    width: 900
    height: 400
---
xychart
  title "Image Size Evolution by Service (Last 30 Days + This PR)"
  x-axis ["11/15 19:34", "11/15 19:47", "11/15 20:39", "11/15 21:23", "11/15 21:37", "11/15 22:04", "11/15 22:28", "11/16 00:55", "11/16 01:28", "11/17 12:35", "11/17 12:48", "11/17 12:54", "11/17 14:13", "11/17 15:17", "11/17 16:07", "11/17 16:55", "11/17 17:33 (PR)"]
  y-axis "Size (GB)" 0 --> 0.5
  line "account-service" [0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11]
  line "authorization-service" [0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11]
  line "ddp-streamer-service" [0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12]
  line "omnichannel-transcript-service" [0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14]
  line "presence-service" [0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11]
  line "queue-worker-service" [0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14, 0.14]
  line "rocketchat" [0.36, 0.36, 0.36, 0.36, 0.36, 0.36, 0.36, 0.36, 0.36, 0.35, 0.35, 0.35, 0.35, 0.35, 0.35, 0.35, 0.36]
  line "stream-hub-service" [0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11, 0.11]

Loading

Statistics (last 16 days):

• 📊 Average: 1.4GiB
• ⬇️ Minimum: 1.2GiB
• ⬆️ Maximum: 1.6GiB
• 🎯 Current PR: 1.2GiB

ℹ️ About this report

This report compares Docker image sizes from this build against the develop baseline.

• Tag: pr-37535
• Baseline: develop
• Timestamp: 2025-11-17 17:33:35 UTC
• Historical data points: 16

---

Updated: Mon, 17 Nov 2025 17:33:35 GMT

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.97%. Comparing base (fcb2d1f) to head (031911c).
⚠️ Report is 2 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #37535   +/-   ##
========================================
  Coverage    68.97%   68.97%           
========================================
  Files         3358     3358           
  Lines       114228   114228           
  Branches     20537    20537           
========================================
+ Hits         78784    78786    +2     
+ Misses       33351    33350    -1     
+ Partials      2093     2092    -1     

Flag	Coverage Δ
e2e	57.44% <ø> (+0.01%)	⬆️
e2e-api	42.81% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.