test(federation): fix test to assert better subscription names when invite comes from Rocket.Chat #37969
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
|
Contributor
WalkthroughThis pull request refactors test user data structures in the federation-matrix end-to-end DM tests. The changes consolidate separate user and config variables (rcUser1/rcUserConfig1, rcUser2/rcUserConfig2) into unified composite objects containing username, fullName, matrixId getter, config, and user properties, updating all dependent references accordingly. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
sampaiodiego
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-8.0.0 #37969 +/- ##
==============================================
Coverage 70.60% 70.60%
==============================================
Files 3146 3146
Lines 108690 108690
Branches 19523 19509 -14
==============================================
+ Hits 76738 76741 +3
+ Misses 29947 29946 -1
+ Partials 2005 2003 -2
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Contributor
📦 Docker Image Size Report📈 Changes
📊 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 22:28", "11/16 01:28", "11/17 23:50", "11/18 22:53", "11/19 23:02", "11/21 16:49", "11/24 17:34", "11/27 22:32", "11/28 19:05", "12/01 23:01", "12/02 21:57", "12/03 21:00", "12/04 18:17", "12/05 21:56", "12/08 20:15", "12/09 22:17", "12/10 23:26", "12/11 21:56", "12/12 22:45", "12/13 01:34", "12/15 22:31", "12/16 22:18", "12/17 21:04", "12/18 23:12", "12/19 23:27", "12/20 21:03", "12/22 18:54", "12/23 16:16", "12/24 18:01 (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, 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, 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, 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.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13]
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, 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.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13]
line "rocketchat" [0.36, 0.36, 0.35, 0.35, 0.35, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.34, 0.35]
Statistics (last 28 days):
ℹ️ About this reportThis report compares Docker image sizes from this build against the
Updated: Wed, 24 Dec 2025 18:01:01 GMT |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts (1)
1173-1191: Same unsafe initialization pattern repeated in multiple test sections.The same type assertion initialization pattern (
{} as IRequestConfig,{} as TestUser<IUser>) is repeated in these additional test sections. The same safety concerns apply here as noted in the earlier comment on lines 864-882.Also applies to: 1357-1375, 1604-1622
📜 Review details
Configuration used: Organization 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.
📒 Files selected for processing (1)
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.spec.ts: Use descriptive test names that clearly communicate expected behavior in Playwright tests
Use.spec.tsextension for test files (e.g.,login.spec.ts)
Files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
🧠 Learnings (11)
📓 Common learnings
Learnt from: sampaiodiego
Repo: RocketChat/Rocket.Chat PR: 37532
File: ee/packages/federation-matrix/src/FederationMatrix.ts:920-927
Timestamp: 2025-12-09T20:01:07.355Z
Learning: In Rocket.Chat's federation invite handling (ee/packages/federation-matrix/src/FederationMatrix.ts), when a user rejects an invite via federationSDK.rejectInvite(), the subscription cleanup happens automatically through an event-driven flow: Matrix emits a leave event back, which is processed by handleLeave() in ee/packages/federation-matrix/src/events/member.ts, and that function calls Room.performUserRemoval() to clean up the subscription. No explicit cleanup is needed in the reject branch of handleInvite() because the leave event handler takes care of it.
<!-- </add_learning>
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.
📚 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/tests/end-to-end/dms.spec.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/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Ensure tests run reliably in parallel without shared state conflicts
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Utilize Playwright fixtures (`test`, `page`, `expect`) for consistency in test files
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-12-10T21:00:54.909Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 37091
File: ee/packages/abac/jest.config.ts:4-7
Timestamp: 2025-12-10T21:00:54.909Z
Learning: Rocket.Chat monorepo: Jest testMatch pattern '<rootDir>/src/**/*.spec.(ts|js|mjs)' is valid in this repo and used across multiple packages (e.g., packages/tools, ee/packages/omnichannel-services). Do not flag it as invalid in future reviews.
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-11-05T21:04:35.787Z
Learnt from: sampaiodiego
Repo: RocketChat/Rocket.Chat PR: 37357
File: ee/packages/federation-matrix/src/setup.ts:103-120
Timestamp: 2025-11-05T21:04:35.787Z
Learning: In Rocket.Chat's federation-matrix setup (ee/packages/federation-matrix/src/setup.ts and apps/meteor/ee/server/startup/federation.ts), configureFederationMatrixSettings does not need to be called before setupFederationMatrix. The SDK's init() establishes infrastructure (database, event handlers, APIs) first, and the configuration can be applied later via settings watchers before actual federation events are processed. The config only matters when events actually occur, at which point all infrastructure is already configured.
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.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/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-12-09T20:01:00.324Z
Learnt from: sampaiodiego
Repo: RocketChat/Rocket.Chat PR: 37532
File: ee/packages/federation-matrix/src/FederationMatrix.ts:920-927
Timestamp: 2025-12-09T20:01:00.324Z
Learning: When reviewing federation invite handling in Rocket.Chat (specifically under ee/packages/federation-matrix), understand that rejecting an invite via federationSDK.rejectInvite() triggers an event-driven cleanup: a leave event is emitted and handled by handleLeave() in ee/packages/federation-matrix/src/events/member.ts, which calls Room.performUserRemoval() to remove the subscription. Do not add explicit cleanup in the reject branch of handleInvite(); rely on the existing leave-event flow for cleanup. If making changes, ensure this invariant remains and that any related paths still funnel cleanup through the leave event to avoid duplicate or missing removals.
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-09-25T09:59:26.461Z
Learnt from: Dnouv
Repo: RocketChat/Rocket.Chat PR: 37057
File: packages/apps-engine/src/definition/accessors/IUserRead.ts:23-27
Timestamp: 2025-09-25T09:59:26.461Z
Learning: AppUserBridge.getUserRoomIds in apps/meteor/app/apps/server/bridges/users.ts always returns an array of strings (mapping subscription documents to room IDs), never undefined, even when user has no room subscriptions.
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
📚 Learning: 2025-09-25T09:59:26.461Z
Learnt from: Dnouv
Repo: RocketChat/Rocket.Chat PR: 37057
File: packages/apps-engine/src/definition/accessors/IUserRead.ts:23-27
Timestamp: 2025-09-25T09:59:26.461Z
Learning: AppUserBridge.getUserRoomIds in apps/meteor/app/apps/server/bridges/users.ts always returns an array of strings by mapping subscription documents to room IDs, never undefined, even when user has no room subscriptions.
Applied to files:
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts
🔇 Additional comments (1)
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts (1)
886-913: Refactoring correctly updates all dependent references.The consolidation of user and config data into composite objects is consistently applied, and all dependent references (deleteUser, getRoomInfo, getSubscriptionByRoomId, etc.) are correctly updated to use the new structure (
.user,.config,.username,.fullNameproperties). The computedmatrixIdgetter is also properly utilized.Also applies to: 918-1012
Comment on lines
+864
to
+882
| const rcUser1 = { | ||
| username: `dm-rc-multi-user1-${Date.now()}`, | ||
| fullName: `DM RC Multi User1 ${Date.now()}`, | ||
| get matrixId() { | ||
| return `@${this.username}:${federationConfig.rc1.domain}`; | ||
| }, | ||
| config: {} as IRequestConfig, | ||
| user: {} as TestUser<IUser>, | ||
| }; | ||
|
|
||
| const rcUserName2 = `dm-rc-multi-user2-${Date.now()}`; | ||
| const rcUserFullName2 = `DM RC Multi User2 ${Date.now()}`; | ||
| const rcUser2 = { | ||
| username: `dm-rc-multi-user2-${Date.now()}`, | ||
| fullName: `DM RC Multi User2 ${Date.now()}`, | ||
| get matrixId() { | ||
| return `@${this.username}:${federationConfig.rc1.domain}`; | ||
| }, | ||
| config: {} as IRequestConfig, | ||
| user: {} as TestUser<IUser>, | ||
| }; |
Contributor
There was a problem hiding this comment.
Unsafe initialization with type assertions could cause runtime errors.
The properties config and user are initialized with empty objects cast to their respective types ({} as IRequestConfig, {} as TestUser<IUser>). This bypasses type safety and creates invalid objects that could cause runtime errors if accessed before beforeAll completes or if setup fails.
🔎 Safer initialization approaches
Option 1: Use optional properties and proper initialization
const rcUser1 = {
username: `dm-rc-multi-user1-${Date.now()}`,
fullName: `DM RC Multi User1 ${Date.now()}`,
get matrixId() {
return `@${this.username}:${federationConfig.rc1.domain}`;
},
- config: {} as IRequestConfig,
- user: {} as TestUser<IUser>,
+ config: undefined as IRequestConfig | undefined,
+ user: undefined as TestUser<IUser> | undefined,
};
const rcUser2 = {
username: `dm-rc-multi-user2-${Date.now()}`,
fullName: `DM RC Multi User2 ${Date.now()}`,
get matrixId() {
return `@${this.username}:${federationConfig.rc1.domain}`;
},
- config: {} as IRequestConfig,
- user: {} as TestUser<IUser>,
+ config: undefined as IRequestConfig | undefined,
+ user: undefined as TestUser<IUser> | undefined,
};Then add non-null assertions when using: rcUser1.config!.request (or check for undefined).
Option 2: Initialize in a factory function
const createUserDescriptor = (username: string, fullName: string) => ({
username,
fullName,
get matrixId() {
return `@${this.username}:${federationConfig.rc1.domain}`;
},
config: null as IRequestConfig | null,
user: null as TestUser<IUser> | null,
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const rcUser1 = { | |
| username: `dm-rc-multi-user1-${Date.now()}`, | |
| fullName: `DM RC Multi User1 ${Date.now()}`, | |
| get matrixId() { | |
| return `@${this.username}:${federationConfig.rc1.domain}`; | |
| }, | |
| config: {} as IRequestConfig, | |
| user: {} as TestUser<IUser>, | |
| }; | |
| const rcUserName2 = `dm-rc-multi-user2-${Date.now()}`; | |
| const rcUserFullName2 = `DM RC Multi User2 ${Date.now()}`; | |
| const rcUser2 = { | |
| username: `dm-rc-multi-user2-${Date.now()}`, | |
| fullName: `DM RC Multi User2 ${Date.now()}`, | |
| get matrixId() { | |
| return `@${this.username}:${federationConfig.rc1.domain}`; | |
| }, | |
| config: {} as IRequestConfig, | |
| user: {} as TestUser<IUser>, | |
| }; | |
| const rcUser1 = { | |
| username: `dm-rc-multi-user1-${Date.now()}`, | |
| fullName: `DM RC Multi User1 ${Date.now()}`, | |
| get matrixId() { | |
| return `@${this.username}:${federationConfig.rc1.domain}`; | |
| }, | |
| config: undefined as IRequestConfig | undefined, | |
| user: undefined as TestUser<IUser> | undefined, | |
| }; | |
| const rcUser2 = { | |
| username: `dm-rc-multi-user2-${Date.now()}`, | |
| fullName: `DM RC Multi User2 ${Date.now()}`, | |
| get matrixId() { | |
| return `@${this.username}:${federationConfig.rc1.domain}`; | |
| }, | |
| config: undefined as IRequestConfig | undefined, | |
| user: undefined as TestUser<IUser> | undefined, | |
| }; |
Comment on lines
+961
to
967
| it("should display only the inviter's username for the invited user on Rocket.Chat", async () => { | ||
| const sub = await getSubscriptionByRoomId(rcRoom._id, rcUser2.config.credentials, rcUser2.config.request); | ||
|
|
||
| expect(sub).toHaveProperty('status', 'INVITED'); | ||
| expect(sub).toHaveProperty('name', rcUser1.name); | ||
| expect(sub).toHaveProperty('fname', rcUser1.username); | ||
| expect(sub).toHaveProperty('name', `${federationConfig.hs1.adminMatrixUserId}, ${rcUser1.username}`); | ||
| expect(sub).toHaveProperty('fname', `${federationConfig.hs1.adminMatrixUserId}, ${rcUser1.fullName}`); | ||
| }); |
Contributor
There was a problem hiding this comment.
Test name doesn't match the assertion.
The test is named "should display only the inviter's username for the invited user on Rocket.Chat" but the assertion checks that the subscription name includes both federationConfig.hs1.adminMatrixUserId and rcUser1.username, not just the inviter's username.
🔎 Suggested fix
-it("should display only the inviter's username for the invited user on Rocket.Chat", async () => {
+it("should display all group DM members for invited Rocket.Chat user from same server", async () => {
const sub = await getSubscriptionByRoomId(rcRoom._id, rcUser2.config.credentials, rcUser2.config.request);
expect(sub).toHaveProperty('status', 'INVITED');
expect(sub).toHaveProperty('name', `${federationConfig.hs1.adminMatrixUserId}, ${rcUser1.username}`);
expect(sub).toHaveProperty('fname', `${federationConfig.hs1.adminMatrixUserId}, ${rcUser1.fullName}`);
});This better reflects that when Rocket.Chat invites another Rocket.Chat user on the same server, it's acceptable to display all members (as mentioned in the PR objectives).
🤖 Prompt for AI Agents
ee/packages/federation-matrix/tests/end-to-end/dms.spec.ts around lines 961 to
967: the test title says "should display only the inviter's username for the
invited user on Rocket.Chat" but the assertions expect the subscription
name/fname to include both the Matrix admin user ID and the inviter's
username/fullName; update the test title to accurately reflect the expectation
(e.g., "should display inviter and Matrix admin identifiers for the invited user
on Rocket.Chat" or similar) so the name matches the assertion, or alternatively
change the assertions to match the original intent if you truly want only the
inviter shown.
ggazzo
approved these changes
Dec 29, 2025
ggazzo
added
the
stat: QA assured
dionisio-bot
bot
added
the
stat: ready to merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes (including videos or screenshots)
Removed the last two
failingtests fromdms.spec.tstest suite to assert that's the behavior we want: when Rocket.Chat sends an invite to another Rocket.Chat user from the same server it's ok to show more information that is already known (like all members of the group DM).Issue(s)
FB-163 and FB-161
Steps to test or reproduce
Further comments
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.