fix: Livechat_accept_chats_with_no_agents omnichannel setting not being respected#40175
Open
nazabucciarelli wants to merge 2 commits intofix/livechat-offline-agent-assignmentfrom
Open
Conversation
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 |
🦋 Changeset detectedLatest commit: 8ebe5d7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 41 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
WalkthroughThreads the Changes
Sequence Diagram(s)sequenceDiagram
rect rgba(220,230,241,0.5)
participant Visitor
participant API
participant RoutingManager
participant UsersModel
participant Database
end
Visitor->>API: send message / start chat
API->>RoutingManager: registerGuest / create visitor (includes shouldConsiderOfflineAgent)
RoutingManager->>UsersModel: find eligible agents (enabledWhenIdle, acceptChatsWithNoAgents)
UsersModel->>Database: query with status filter (may include offline agents if flag true)
Database-->>UsersModel: return candidate agents
UsersModel-->>RoutingManager: selected agent (or none)
RoutingManager-->>API: return routing decision / assign room
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## fix/livechat-offline-agent-assignment #40175 +/- ##
=========================================================================
+ Coverage 70.16% 70.18% +0.01%
=========================================================================
Files 3281 3281
Lines 116915 116915
Branches 20815 20697 -118
=========================================================================
+ Hits 82037 82054 +17
+ Misses 31594 31570 -24
- Partials 3284 3291 +7
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![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.
🧹 Nitpick comments (1)
apps/meteor/tests/end-to-end/api/livechat/24-routing.ts (1)
399-399: Removeasyncfromdescribecallbacks.Mocha
describecallbacks should be synchronous. Whileasynchas no semantic effect here (Mocha doesn't await suite definitions), it adds unnecessary syntax and reduces clarity. The async work correctly remains inbefore/afterhooks.Proposed fix
- describe('Auto_Selection - Livechat_accept_chats_with_no_agents', async () => { + describe('Auto_Selection - Livechat_accept_chats_with_no_agents', () => {- describe('Load_Balancing - Livechat_accept_chats_with_no_agents', async () => { + describe('Load_Balancing - Livechat_accept_chats_with_no_agents', () => {- describe('Load_Rotation - Livechat_accept_chats_with_no_agents', async () => { + describe('Load_Rotation - Livechat_accept_chats_with_no_agents', () => {Also applies to: 526-526, 654-654
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/tests/end-to-end/api/livechat/24-routing.ts` at line 399, Remove the unnecessary async keyword from the suite definitions: change the describe callbacks that declare "Auto_Selection - Livechat_accept_chats_with_no_agents" (and the other describe callbacks flagged at the same file) to be synchronous by removing the async modifier; leave any async logic in before/after/it hooks (e.g., async functions used inside before/afterEach/it remain unchanged). Specifically, locate the describe(...) blocks with the title "Auto_Selection - Livechat_accept_chats_with_no_agents" and the other two describe callbacks referenced and delete the leading async from their callback signatures so the suites are defined synchronously.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/meteor/tests/end-to-end/api/livechat/24-routing.ts`:
- Line 399: Remove the unnecessary async keyword from the suite definitions:
change the describe callbacks that declare "Auto_Selection -
Livechat_accept_chats_with_no_agents" (and the other describe callbacks flagged
at the same file) to be synchronous by removing the async modifier; leave any
async logic in before/after/it hooks (e.g., async functions used inside
before/afterEach/it remain unchanged). Specifically, locate the describe(...)
blocks with the title "Auto_Selection - Livechat_accept_chats_with_no_agents"
and the other two describe callbacks referenced and delete the leading async
from their callback signatures so the suites are defined synchronously.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1231c6be-a4ab-4587-ba69-be6c9a7063e8
📒 Files selected for processing (26)
.changeset/wet-pandas-pump.mdapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/departmentsLib.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tsapps/meteor/ee/server/models/raw/Users.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/helpers/omnichannel/agentStatus.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/models/src/models/Users.tspackages/omni-core/src/visitor/create.spec.tspackages/omni-core/src/visitor/create.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: cubic · AI code reviewer
🧰 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:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/server/models/raw/Users.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.tspackages/models/src/helpers/omnichannel/agentStatus.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.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:
packages/omni-core/src/visitor/create.spec.ts
🧠 Learnings (38)
📓 Common learnings
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39677
File: packages/models/src/helpers/omnichannel/agentStatus.ts:10-29
Timestamp: 2026-03-16T22:56:54.500Z
Learning: In `packages/models/src/helpers/omnichannel/agentStatus.ts` (PR `#39677`), the `queryStatusAgentOnline` function intentionally omits the `$or` offline-status guard for non-bot agents when `isLivechatEnabledWhenAgentIdle === true`. This is by design: the setting `Livechat_enabled_when_agent_idle` (`accept_chats_when_agent_idle`) means agents should receive chats even when idle/offline, so the offline filter must be removed in that path. Bots are always status-agnostic and are always included regardless of their online/offline status. Do not flag this as a bug.
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39657
File: apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts:18-21
Timestamp: 2026-03-16T11:50:18.066Z
Learning: In `apps/meteor/tests/end-to-end/apps/` (and Livechat E2E tests broadly), calling `createAgent()` and `makeAgentAvailable()` immediately after `updateSetting('Livechat_enabled', true)` — without any intermediate sleep — is an established, non-flaky pattern used across 10+ tests in the codebase. Do not flag this sequence as a potential race condition or suggest adding a delay between them.
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39250
File: apps/meteor/tests/end-to-end/api/livechat/07-queue.ts:1084-1094
Timestamp: 2026-03-02T16:31:41.304Z
Learning: In E2E API tests at apps/meteor/tests/end-to-end/api/livechat/, using sleep(1000) after updateSetting() or updateEESetting() calls in test setup hooks is acceptable and intentional to allow omnichannel settings to propagate their side effects.
📚 Learning: 2026-03-11T16:46:55.955Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39535
File: apps/meteor/app/apps/server/bridges/livechat.ts:249-249
Timestamp: 2026-03-11T16:46:55.955Z
Learning: In `apps/meteor/app/apps/server/bridges/livechat.ts`, `createVisitor()` intentionally does not propagate `externalIds` to `registerData`. This is by design: the method is deprecated (JSDoc: `deprecated Use createAndReturnVisitor instead. Note: This method does not support externalIds.`) to push callers toward `createAndReturnVisitor()`, which does support `externalIds`. Do not flag the missing `externalIds` field in `createVisitor()` as a bug.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tspackages/models/src/models/Users.ts
📚 Learning: 2026-03-16T22:56:54.500Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39677
File: packages/models/src/helpers/omnichannel/agentStatus.ts:10-29
Timestamp: 2026-03-16T22:56:54.500Z
Learning: In `packages/models/src/helpers/omnichannel/agentStatus.ts` (PR `#39677`), the `queryStatusAgentOnline` function intentionally omits the `$or` offline-status guard for non-bot agents when `isLivechatEnabledWhenAgentIdle === true`. This is by design: the setting `Livechat_enabled_when_agent_idle` (`accept_chats_when_agent_idle`) means agents should receive chats even when idle/offline, so the offline filter must be removed in that path. Bots are always status-agnostic and are always included regardless of their online/offline status. Do not flag this as a bug.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.ts.changeset/wet-pandas-pump.mdapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/server/models/raw/Users.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.ts
📚 Learning: 2026-03-31T23:29:12.037Z
Learnt from: nazabucciarelli
Repo: RocketChat/Rocket.Chat PR: 39905
File: packages/models/src/models/LivechatVisitors.ts:391-406
Timestamp: 2026-03-31T23:29:12.037Z
Learning: In `packages/models/src/models/LivechatVisitors.ts`, `saveGuestEmailPhoneById` uses a two-step approach: (1) a `{ visitorEmails: null }` / `{ phone: null }` guard to lazily initialize legacy null fields to empty arrays (concurrency-safe: subsequent concurrent calls simply skip the no-match), then (2) `$addToSet` with `$each` to append without reordering. This is intentional and correct. Do not flag concurrency or ordering concerns: `visitorEmails[0]` is the primary email set during visitor registration and is never displaced by `$addToSet`; the `leadCapture` hook is a data-scraping bucket where entry order is irrelevant to business logic.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tspackages/models/src/models/Users.ts
📚 Learning: 2026-03-11T22:04:20.529Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 39545
File: apps/meteor/client/views/room/body/hooks/useHasNewMessages.ts:59-61
Timestamp: 2026-03-11T22:04:20.529Z
Learning: In `apps/meteor/client/views/room/body/hooks/useHasNewMessages.ts`, the `msg.u._id === uid` early-return in the `streamNewMessage` handler is intentional: the "New messages" indicator is designed to notify about messages from other users only. Self-sent messages — including those sent from a different session/device — are always skipped, by design. Do not flag this as a multi-session regression.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tsapps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2025-11-19T18:20:37.116Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 37419
File: apps/meteor/server/services/media-call/service.ts:141-141
Timestamp: 2025-11-19T18:20:37.116Z
Learning: In apps/meteor/server/services/media-call/service.ts, the sendHistoryMessage method should use call.caller.id or call.createdBy?.id as the message author, not call.transferredBy?.id. Even for transferred calls, the message should appear in the DM between the two users who are calling each other, not sent by the person who transferred the call.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/lib/takeInquiry.ts
📚 Learning: 2026-03-15T14:31:28.969Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-03-03T11:11:48.541Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39230
File: apps/meteor/app/api/server/v1/chat.ts:214-222
Timestamp: 2026-03-03T11:11:48.541Z
Learning: In apps/meteor/server/lib/moderation/reportMessage.ts, the reportMessage function validates that description is not empty or whitespace-only with `if (!description.trim())`. When migrating the chat.reportMessage endpoint to OpenAPI, adding minLength validation to the schema preserves this existing behavior.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/message.ts
📚 Learning: 2026-03-12T10:26:26.697Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39340
File: apps/meteor/app/api/server/v1/im.ts:1349-1398
Timestamp: 2026-03-12T10:26:26.697Z
Learning: In `apps/meteor/app/api/server/v1/im.ts` (PR `#39340`), the `DmEndpoints` type intentionally includes temporary stub entries for `/v1/im.kick`, `/v1/dm.kick`, `/v1/im.leave`, and `/v1/dm.leave` (using `DmKickProps` and `DmLeaveProps`) even though no route handlers exist for them yet. These stubs were added to preserve type compatibility after removing the original `DmLeaveProps` and related files. They are planned for cleanup in a follow-up PR. Do not flag these as missing implementations when reviewing this file until the follow-up is merged.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/server/models/raw/Users.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.tspackages/models/src/helpers/omnichannel/agentStatus.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
apps/meteor/app/livechat/imports/server/rest/sms.tsapps/meteor/app/livechat/server/api/v1/visitor.tsapps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tsapps/meteor/app/livechat/server/lib/departmentsLib.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/server/models/raw/Users.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.tspackages/models/src/helpers/omnichannel/agentStatus.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.ts
📚 Learning: 2026-03-20T13:51:23.302Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts:179-181
Timestamp: 2026-03-20T13:51:23.302Z
Learning: In `apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts`, the truthiness guards `...(integration.avatar && { avatar })`, `...(integration.emoji && { emoji })`, `...(integration.alias && { alias })`, and `...(integration.script && { script })` in the `$set` payload of `updateIncomingIntegration` are intentional. Empty-string values for these fields should NOT overwrite the stored value — only truthy values are persisted. Do not flag these as bugs preventing explicit clears.
Applied to files:
apps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-03-18T22:07:19.687Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 38357
File: apps/meteor/app/apps/server/converters/departments.ts:59-70
Timestamp: 2026-03-18T22:07:19.687Z
Learning: In `apps/meteor/app/apps/server/converters/departments.ts`, the `convertAppDepartment` method uses non-null assertions (`!`) on `department.name`, `department.email`, and `department.offlineMessageChannelName` when constructing `newDepartment: ILivechatDepartment`. These fields are optional on `IAppsDepartment`, but the App framework flow guarantees their presence at the call site. Do not flag these non-null assertions as unsafe during code review.
Applied to files:
apps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/apps/server/bridges/livechat.tspackages/models/src/models/LivechatDepartmentAgents.tspackages/omni-core/src/visitor/create.spec.tsapps/meteor/app/livechat/server/lib/Helper.tspackages/model-typings/src/models/ILivechatDepartmentAgentsModel.tsapps/meteor/app/livechat/server/lib/departmentsLib.ts
📚 Learning: 2026-03-16T21:50:42.118Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.
Applied to files:
apps/meteor/app/livechat/server/api/v1/message.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2026-01-17T01:51:47.764Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 38219
File: packages/core-typings/src/cloud/Announcement.ts:5-6
Timestamp: 2026-01-17T01:51:47.764Z
Learning: In packages/core-typings/src/cloud/Announcement.ts, the AnnouncementSchema.createdBy field intentionally overrides IBannerSchema.createdBy (object with _id and optional username) with a string enum ['cloud', 'system'] to match existing runtime behavior. This is documented as technical debt with a FIXME comment at apps/meteor/app/cloud/server/functions/syncWorkspace/handleCommsSync.ts:53 and should not be flagged as an error until the runtime behavior is corrected.
Applied to files:
apps/meteor/server/features/EmailInbox/EmailInbox_Incoming.ts
📚 Learning: 2026-03-16T11:50:18.066Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39657
File: apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts:18-21
Timestamp: 2026-03-16T11:50:18.066Z
Learning: In `apps/meteor/tests/end-to-end/apps/` (and Livechat E2E tests broadly), calling `createAgent()` and `makeAgentAvailable()` immediately after `updateSetting('Livechat_enabled', true)` — without any intermediate sleep — is an established, non-flaky pattern used across 10+ tests in the codebase. Do not flag this sequence as a potential race condition or suggest adding a delay between them.
Applied to files:
apps/meteor/server/features/EmailInbox/EmailInbox_Incoming.tsapps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.tsapps/meteor/app/livechat/server/lib/takeInquiry.ts.changeset/wet-pandas-pump.mdapps/meteor/app/livechat/server/lib/routing/AutoSelection.tsapps/meteor/app/livechat/server/lib/service-status.tsapps/meteor/app/livechat/server/lib/QueueManager.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.tsapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.tsapps/meteor/app/livechat/server/lib/departmentsLib.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2026-03-16T11:57:17.987Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39657
File: apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts:43-45
Timestamp: 2026-03-16T11:57:17.987Z
Learning: In `apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts`, `externalIds` lookups are namespaced per `app.id`. Because `cleanupApps()` is called before each test run and a fresh app is installed (giving a new unique `app.id`), fixed `userId` strings like `'nonexistent-id'` in null-path tests are safe and cannot collide with stale visitor records from previous runs. Do not flag these as needing unique/random values.
Applied to files:
apps/meteor/app/livechat/server/lib/routing/External.tspackages/omni-core/src/visitor/create.spec.ts
📚 Learning: 2026-03-14T14:58:58.834Z
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Applied to files:
apps/meteor/app/livechat/server/lib/routing/External.tsapps/meteor/app/livechat/server/lib/RoutingManager.ts.changeset/wet-pandas-pump.mdapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2026-02-24T19:09:09.561Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
Applied to files:
apps/meteor/app/livechat/server/lib/routing/External.ts.changeset/wet-pandas-pump.md
📚 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:
apps/meteor/app/livechat/server/lib/RoutingManager.ts.changeset/wet-pandas-pump.mdapps/meteor/app/apps/server/bridges/livechat.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tsapps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/app/livechat/server/lib/departmentsLib.ts
📚 Learning: 2026-04-13T16:40:55.864Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 40100
File: apps/meteor/client/views/root/MainLayout/EmbeddedPreload.tsx:18-35
Timestamp: 2026-04-13T16:40:55.864Z
Learning: In Rocket.Chat's embedded mode (`?layout=embedded`), route changes are driven by the parent frame reloading the iframe URL, which causes a full remount of the React tree (including `EmbeddedPreload` at `apps/meteor/client/views/root/MainLayout/EmbeddedPreload.tsx`). The component never survives a navigation, so `roomParams` (computed via `useMemo`) is always fresh on mount. A `[router]` singleton as the sole `useMemo` dependency is therefore correct and intentional — do not flag it as a stale-dependency bug in this component.
Applied to files:
apps/meteor/app/livechat/server/lib/RoutingManager.ts
📚 Learning: 2026-03-15T14:31:23.493Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:891-899
Timestamp: 2026-03-15T14:31:23.493Z
Learning: In RocketChat/Rocket.Chat, `IUser.inactiveReason` in `packages/core-typings/src/IUser.ts` is typed as `'deactivated' | 'pending_approval' | 'idle_too_long'` (optional, no `null`), but the database stores `null` for newly created users. The Typia-generated `$ref: '#/components/schemas/IUser'` schema therefore correctly rejects `null` for `inactiveReason`. This causes the test "should create a new user with default roles" to fail when response validation is active (TEST_MODE). The fix is to add `| null` to `inactiveReason` in core-typings and rebuild Typia schemas in a separate PR. Do not flag this test failure as a bug introduced by the users.create OpenAPI migration (PR `#39647`). Do not suggest inlining a custom schema to work around it, as migration rules require using `$ref` when a Typia schema exists.
Applied to files:
apps/meteor/app/livechat/server/lib/takeInquiry.tspackages/omni-core/src/visitor/create.spec.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.ts
📚 Learning: 2026-03-16T21:50:37.589Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:37.589Z
Learning: For changes related to OpenAPI migrations in Rocket.Chat/OpenAPI, when removing endpoint types and validators from rocket.chat/rest-typings (e.g., UserRegisterParamsPOST, /v1/users.register) document this as a minor changeset (not breaking) per RocketChat/Rocket.Chat-Open-API#150 Rule 7. Note that the endpoint type is re-exposed via a module augmentation .d.ts in the consuming package (e.g., packages/web-ui-registration/src/users-register.d.ts). In reviews, ensure the changeset clearly states: this is a non-breaking change, the major version should not be bumped, and the changeset reflects a minor version bump. Do not treat this as a breaking change during OpenAPI migrations.
Applied to files:
.changeset/wet-pandas-pump.md
📚 Learning: 2026-02-25T20:10:16.987Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38913
File: packages/ddp-client/src/legacy/types/SDKLegacy.ts:34-34
Timestamp: 2026-02-25T20:10:16.987Z
Learning: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references. Module augmentations in apps/meteor (e.g., declare module 'rocket.chat/rest-typings') are not visible when compiling packages/ddp-client in isolation, which is why legacy SDK methods that depend on OperationResult types for OpenAPI-migrated endpoints must remain commented out.
Applied to files:
.changeset/wet-pandas-pump.md
📚 Learning: 2026-03-02T16:31:41.304Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39250
File: apps/meteor/tests/end-to-end/api/livechat/07-queue.ts:1084-1094
Timestamp: 2026-03-02T16:31:41.304Z
Learning: In E2E API tests at apps/meteor/tests/end-to-end/api/livechat/, using sleep(1000) after updateSetting() or updateEESetting() calls in test setup hooks is acceptable and intentional to allow omnichannel settings to propagate their side effects.
Applied to files:
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2025-11-27T17:56:26.050Z
Learnt from: MartinSchoeler
Repo: RocketChat/Rocket.Chat PR: 37557
File: apps/meteor/client/views/admin/ABAC/AdminABACRooms.tsx:115-116
Timestamp: 2025-11-27T17:56:26.050Z
Learning: In Rocket.Chat, the GET /v1/abac/rooms endpoint (implemented in ee/packages/abac/src/index.ts) only returns rooms where abacAttributes exists and is not an empty array (query: { abacAttributes: { $exists: true, $ne: [] } }). Therefore, in components consuming this endpoint (like AdminABACRooms.tsx), room.abacAttributes is guaranteed to be defined for all returned rooms, and optional chaining before calling array methods like .join() is sufficient without additional null coalescing.
Applied to files:
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-09T18:39:21.178Z
Learnt from: Harxhit
Repo: RocketChat/Rocket.Chat PR: 39476
File: apps/meteor/server/methods/addAllUserToRoom.ts:0-0
Timestamp: 2026-03-09T18:39:21.178Z
Learning: In apps/meteor/server/methods/addAllUserToRoom.ts, the implementation uses a single cursor pass (Users.find(userFilter).batchSize(100)) that collects both the full user objects (collectedUsers: IUser[]) and their usernames (usernames: string[]) in one iteration. `beforeAddUserToRoom` is then called once with the full usernames batch (preserving batch-validation semantics), and the subsequent subscription/message processing loop iterates over the same stable `collectedUsers` array — no second DB query is made. This avoids any race condition between validation and processing while preserving the original batch-validation behavior.
Applied to files:
packages/models/src/models/LivechatDepartmentAgents.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:
packages/omni-core/src/visitor/create.spec.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.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:
packages/omni-core/src/visitor/create.spec.tsapps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2025-12-10T21:00:43.645Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 37091
File: ee/packages/abac/jest.config.ts:4-7
Timestamp: 2025-12-10T21:00:43.645Z
Learning: Adopt the monorepo-wide Jest testMatch pattern: <rootDir>/src/**/*.spec.{ts,js,mjs} (represented here as '**/src/**/*.spec.{ts,js,mjs}') to ensure spec files under any package's src directory are picked up consistently across all packages in the Rocket.Chat monorepo. Apply this pattern in jest.config.ts for all relevant packages to maintain uniform test discovery.
Applied to files:
packages/omni-core/src/visitor/create.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 : Use `expect` matchers for assertions (`toEqual`, `toContain`, `toBeTruthy`, `toHaveLength`, etc.) instead of `assert` statements in Playwright tests
Applied to files:
packages/omni-core/src/visitor/create.spec.ts
📚 Learning: 2026-02-24T19:22:48.358Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:48.358Z
Learning: In Playwright end-to-end tests (e.g., under apps/meteor/tests/e2e/...), prefer locating elements by translated text (getByText) and ARIA roles (getByRole) over data-qa attributes. If translation values change, update the corresponding test locators accordingly. Never use data-qa locators. This guideline applies to all Playwright e2e test specs in the repository and helps keep tests robust to UI text changes and accessible semantics.
Applied to files:
packages/omni-core/src/visitor/create.spec.ts
📚 Learning: 2026-03-06T18:10:15.268Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39397
File: packages/gazzodown/src/code/CodeBlock.spec.tsx:47-68
Timestamp: 2026-03-06T18:10:15.268Z
Learning: In tests (especially those using testing-library/dom/jsdom) for Rocket.Chat components, the HTML <code> element has an implicit ARIA role of 'code'. Therefore, screen.getByRole('code') or screen.findByRole('code') will locate <code> elements even without a role attribute. Do not flag findByRole('code') as invalid in reviews; prefer using the implicit role instead of adding role="code" unless necessary for accessibility.
Applied to files:
packages/omni-core/src/visitor/create.spec.ts
📚 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:
apps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2025-12-18T15:18:31.688Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 37773
File: apps/meteor/client/views/mediaCallHistory/MediaCallHistoryInternal.tsx:24-34
Timestamp: 2025-12-18T15:18:31.688Z
Learning: In apps/meteor/client/views/mediaCallHistory/MediaCallHistoryInternal.tsx, for internal call history items, the item.contactId is guaranteed to always match either the caller.id or callee.id in the call data, so the contact resolution in getContact will never result in undefined.
Applied to files:
packages/omni-core/src/visitor/create.ts
📚 Learning: 2026-02-24T19:36:55.089Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/page-objects/fragments/home-content.ts:60-82
Timestamp: 2026-02-24T19:36:55.089Z
Learning: In RocketChat/Rocket.Chat e2e tests (apps/meteor/tests/e2e/page-objects/fragments/home-content.ts), thread message preview listitems do not have aria-roledescription="message", so lastThreadMessagePreview locator cannot be scoped to messageListItems (which filters for aria-roledescription="message"). It should remain scoped to page.getByRole('listitem') or mainMessageList.getByRole('listitem').
Applied to files:
apps/meteor/tests/end-to-end/api/livechat/24-routing.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:
apps/meteor/tests/end-to-end/api/livechat/24-routing.ts
📚 Learning: 2026-03-16T22:56:50.405Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39677
File: packages/models/src/helpers/omnichannel/agentStatus.ts:10-29
Timestamp: 2026-03-16T22:56:50.405Z
Learning: In packages/models/src/helpers/omnichannel/agentStatus.ts, document and preserve the design: when isLivechatEnabledWhenAgentIdle (Livechat_enabled_when_agent_idle) is true, the offline-status guard should be omitted for non-bot agents in queryStatusAgentOnline, so idle/offline agents can still receive chats. Bots should always be included regardless of their online/offline status. Do not flag this as a bug; this is an intentional behavior and should be clearly noted in code comments and related tests. This guidance applies specifically to this file and its related logic for agent provisioning in livechat.
Applied to files:
packages/models/src/helpers/omnichannel/agentStatus.ts
🪛 LanguageTool
.changeset/wet-pandas-pump.md
[style] ~7-~7: Consider using a different verb for a more formal wording.
Context: ...patch '@rocket.chat/meteor': patch --- Fixed an issue where the Omnichannel routing ...
(FIX_RESOLVE)
[style] ~8-~8: Try moving the adverb to make the sentence clearer.
Context: ...he agent availability queries have been updated to properly evaluate this setting, ensuring offline agents are correctly ...
(SPLIT_INFINITIVE)
🔇 Additional comments (30)
packages/model-typings/src/models/ILivechatDepartmentAgentsModel.ts (1)
56-62: Interface contract update looks correct.Adding
acceptChatsWithNoAgentsas a trailing optional parameter cleanly extends the contract without breaking existing callers.apps/meteor/app/livechat/server/api/v1/visitor.ts (1)
62-65: Guest registration now correctly includes offline-agent policy.This change properly propagates
Livechat_accept_chats_with_no_agentsintoregisterGuest, matching the new routing intent.apps/meteor/app/livechat/imports/server/rest/sms.ts (1)
76-77: SMS visitor flow is now aligned with omnichannel setting behavior.Passing
shouldConsiderOfflineAgenthere closes a previously inconsistent registration path.apps/meteor/app/livechat/server/api/v1/message.ts (1)
275-278:livechat/messagesregistration path now respects offline-agent acceptance.Good propagation of the new setting into this
registerGuestcall.apps/meteor/app/apps/server/bridges/livechat.ts (2)
227-230:createVisitornow passes the offline-agent flag correctly.This keeps app-triggered visitor creation aligned with livechat routing policy.
257-260:createAndReturnVisitoris correctly updated as well.Nice consistency across both app bridge visitor creation methods.
apps/meteor/server/features/EmailInbox/EmailInbox_Incoming.ts (1)
51-54: Email inbox guest registration now honors the offline-agent setting.This closes another important ingress path and improves behavior consistency.
apps/meteor/app/livechat/server/lib/QueueManager.ts (1)
446-451: Unarchive assignment path is correctly updated.Including
Livechat_accept_chats_with_no_agentshere ensures restored conversations follow current routing policy too.apps/meteor/app/livechat/server/lib/Helper.ts (2)
499-504: Forward-to-agent eligibility now correctly considers offline-agent acceptance.This aligns agent transfer checks with the updated omnichannel setting behavior.
665-670: Forward-to-department-with-agent path is consistently updated.Good to see the same offline-agent flag applied in this transfer branch as well.
apps/meteor/app/livechat/server/lib/routing/External.ts (1)
60-65: LGTM: external queue validation now respects the offline-routing flag.This keeps externally selected agents aligned with the same eligibility rules used by the built-in routing paths.
.changeset/wet-pandas-pump.md (1)
1-8: LGTM: the changeset matches the scope of the routing fix.The patch bumps and summary text are consistent with the behavioral change in this PR.
apps/meteor/app/livechat/server/lib/service-status.ts (2)
11-25: LGTM:getOnlineAgentsnow uses the same offline-eligibility input as routing.That closes the gap between agent lookup and assignment behavior for non-department availability checks.
54-81: LGTM:checkOnlineAgentsis now consistent with the updated agent-selection rules.Both the targeted-agent and fallback checks now evaluate
Livechat_accept_chats_with_no_agents.apps/meteor/app/livechat/server/lib/RoutingManager.ts (1)
111-120: LGTM: delegate fallback now validates the agent with the updated eligibility rules.This keeps direct delegation aligned with the same offline-agent behavior used by queue selection.
apps/meteor/app/livechat/server/lib/takeInquiry.ts (1)
29-40: LGTM: manual take now honorsLivechat_accept_chats_with_no_agentstoo.Including the setting in the
TEST_MODEerror payload is also useful for diagnosing routing-test failures.apps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadRotation.ts (1)
33-45: LGTM: load rotation now threads the offline flag through both filtering steps.Passing
enabledWhenOfflineinto unavailable-agent resolution and last-routed selection keeps this strategy internally consistent.apps/meteor/app/livechat/server/lib/routing/AutoSelection.ts (1)
33-47: LGTM: both auto-selection paths now forward the new routing flag.That removes the previous mismatch between department and global agent selection.
apps/meteor/ee/app/livechat-enterprise/server/lib/routing/LoadBalancing.ts (1)
34-46: LGTM: load balancing now appliesenabledWhenOfflineconsistently.Using the flag in both unavailable-agent pruning and least-busy selection keeps this routing mode aligned with the rest of the PR.
apps/meteor/app/livechat/server/lib/departmentsLib.ts (1)
292-299:Livechat_accept_chats_with_no_agentsis correctly threaded into department availability checks.Both department-level lookup paths now pass the offline-acceptance flag, which keeps availability resolution aligned with routing behavior.
Also applies to: 308-312
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts (1)
26-33: Default-agent fallback paths now consistently honor offline-agent acceptance.Good propagation of
Livechat_accept_chats_with_no_agentsacross ID-based and username-based resolution flows.Also applies to: 47-52, 136-141
packages/models/src/models/LivechatDepartmentAgents.ts (1)
176-182: Agent selection inputs are now internally consistent for offline acceptance.Nice update: both candidate discovery and unavailable-agent filtering consume the same
acceptChatsWithNoAgentssignal.Also applies to: 189-193, 198-200
packages/omni-core/src/visitor/create.ts (1)
20-21: Guest registration now correctly propagates offline-agent eligibility into contact-manager lookup.This keeps visitor assignment behavior aligned with the new omnichannel setting.
Also applies to: 43-50
packages/omni-core/src/visitor/create.spec.ts (1)
72-75: Test suite update is solid and verifies the new parameter propagation end-to-end withinregisterGuest.The added assertions on
findOneOnlineAgentByIdargument shape materially improve regression coverage for this setting change.Also applies to: 82-85, 113-123, 159-160, 187-188, 219-220, 248-251, 271-272, 303-304, 336-337, 369-370, 401-402, 429-430, 459-460, 490-491, 518-519, 543-544, 569-570, 604-605, 638-639, 668-669, 698-699, 724-727, 731-766
apps/meteor/ee/server/models/raw/Users.ts (1)
9-14:getUnavailableAgentscorrectly incorporates offline-agent policy now.Good alignment between typing, implementation defaults, and query construction.
Also applies to: 23-28, 58-59
packages/models/src/helpers/omnichannel/agentStatus.ts (1)
14-18: Core agent-status query changes look correct and consistent.
acceptChatsWithNoAgentsis now properly propagated through both status-query helpers used by selection/routing.Also applies to: 23-33, 40-46
apps/meteor/tests/end-to-end/api/livechat/24-routing.ts (1)
399-444: Great coverage addition forLivechat_accept_chats_with_no_agentsacross all routing strategies.The new ON/OFF assertions for Auto Selection, Load Balancing, and Load Rotation directly exercise the regression surface from CORE-1972.
Also applies to: 526-572, 654-700
packages/model-typings/src/models/IUsersModel.ts (1)
108-121: Nice API alignment.Appending
acceptChatsWithNoAgentsconsistently across the routing-facing signatures keeps the typings in sync with the updated availability helpers and downstream call sites.Also applies to: 252-310
packages/models/src/models/Users.ts (2)
554-565: Good helper threading.These entry points now consistently forward
acceptChatsWithNoAgentsinto the shared omnichannel query builders, so the setting is applied the same way across selection, lookup, and existence checks.Also applies to: 637-648, 1623-1635, 1649-1662, 1878-1923, 1945-1963
1623-1646: These count methods are unused in the codebase and do not participate in livechat routing.The
countOnlineUserFromList()andcountOnlineAgents()methods have zero call sites across the entire repository — they appear only in type definitions and their implementations. The actively-used routing logic (departmentsLib.ts, service-status.ts, QueueManager.ts, Helper.ts) relies exclusively onfindOnlineUserFromList(),findOnlineAgents(), andcheckOnlineAgents(), which already accept theacceptChatsWithNoAgentsparameter.Since the count methods are not called by any routing gate or availability decision, the lack of the
acceptChatsWithNoAgentsparameter poses no routing inconsistency.
KevLehman
requested changes
Apr 16, 2026
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts (1)
26-41: Offline fallback at lines 38-41 now has narrower scope — confirm intent.After this change,
findOneOnlineAgentByIdalready returns offline agents withstatusLivechat=availablewhen the setting is true. The remainingfindOneAgentByIdfallback only matches agents whose omnichannel toggle is off (statusLivechat=not-available). That overlaps with the "ghost agent" concern from CORE-1853 — routing may still pick agents who have explicitly turned themselves unavailable.If that’s not desired, the fallback block can be removed; if it’s intentional (preserving legacy behavior), no change needed.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts` around lines 26 - 41, The fallback using Users.findOneAgentById can still select agents who explicitly set statusLivechat=not-available; decide desired behavior and act accordingly: if you want to prevent routing to agents who manually turned off omnichannel, remove the offline fallback (delete the Users.findOneAgentById block and its normalizeDefaultAgent return); if you intend to keep legacy behavior, make the intent explicit by adding a guard to the fallback to exclude statusLivechat==='not-available' (or only allow when settings.get('Livechat_accept_chats_with_no_agents') is true and agent.statusLivechat !== 'not-available'), and add/update tests covering both branches. Reference: Users.findOneOnlineAgentById, Users.findOneAgentById, normalizeDefaultAgent, and the Livechat_accept_chats_with_no_agents setting.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts`:
- Around line 26-41: The fallback using Users.findOneAgentById can still select
agents who explicitly set statusLivechat=not-available; decide desired behavior
and act accordingly: if you want to prevent routing to agents who manually
turned off omnichannel, remove the offline fallback (delete the
Users.findOneAgentById block and its normalizeDefaultAgent return); if you
intend to keep legacy behavior, make the intent explicit by adding a guard to
the fallback to exclude statusLivechat==='not-available' (or only allow when
settings.get('Livechat_accept_chats_with_no_agents') is true and
agent.statusLivechat !== 'not-available'), and add/update tests covering both
branches. Reference: Users.findOneOnlineAgentById, Users.findOneAgentById,
normalizeDefaultAgent, and the Livechat_accept_chats_with_no_agents setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 79159f93-7464-4cb0-a514-95ebc1c63743
📒 Files selected for processing (7)
apps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/app/livechat/server/lib/takeInquiry.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.tspackages/model-typings/src/models/IUsersModel.tspackages/models/src/models/Users.tspackages/omni-core/src/visitor/create.spec.tspackages/omni-core/src/visitor/create.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- apps/meteor/app/livechat/server/lib/takeInquiry.ts
- packages/omni-core/src/visitor/create.spec.ts
- packages/model-typings/src/models/IUsersModel.ts
- packages/models/src/models/Users.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: 📦 Build Packages
- GitHub Check: CodeQL-Build
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{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:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
🧠 Learnings (17)
📓 Common learnings
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39677
File: packages/models/src/helpers/omnichannel/agentStatus.ts:10-29
Timestamp: 2026-03-16T22:56:54.500Z
Learning: In `packages/models/src/helpers/omnichannel/agentStatus.ts` (PR `#39677`), the `queryStatusAgentOnline` function intentionally omits the `$or` offline-status guard for non-bot agents when `isLivechatEnabledWhenAgentIdle === true`. This is by design: the setting `Livechat_enabled_when_agent_idle` (`accept_chats_when_agent_idle`) means agents should receive chats even when idle/offline, so the offline filter must be removed in that path. Bots are always status-agnostic and are always included regardless of their online/offline status. Do not flag this as a bug.
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39657
File: apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts:18-21
Timestamp: 2026-03-16T11:50:18.066Z
Learning: In `apps/meteor/tests/end-to-end/apps/` (and Livechat E2E tests broadly), calling `createAgent()` and `makeAgentAvailable()` immediately after `updateSetting('Livechat_enabled', true)` — without any intermediate sleep — is an established, non-flaky pattern used across 10+ tests in the codebase. Do not flag this sequence as a potential race condition or suggest adding a delay between them.
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39250
File: apps/meteor/tests/end-to-end/api/livechat/07-queue.ts:1084-1094
Timestamp: 2026-03-02T16:31:41.304Z
Learning: In E2E API tests at apps/meteor/tests/end-to-end/api/livechat/, using sleep(1000) after updateSetting() or updateEESetting() calls in test setup hooks is acceptable and intentional to allow omnichannel settings to propagate their side effects.
📚 Learning: 2026-03-16T22:56:54.500Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39677
File: packages/models/src/helpers/omnichannel/agentStatus.ts:10-29
Timestamp: 2026-03-16T22:56:54.500Z
Learning: In `packages/models/src/helpers/omnichannel/agentStatus.ts` (PR `#39677`), the `queryStatusAgentOnline` function intentionally omits the `$or` offline-status guard for non-bot agents when `isLivechatEnabledWhenAgentIdle === true`. This is by design: the setting `Livechat_enabled_when_agent_idle` (`accept_chats_when_agent_idle`) means agents should receive chats even when idle/offline, so the offline filter must be removed in that path. Bots are always status-agnostic and are always included regardless of their online/offline status. Do not flag this as a bug.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-18T22:07:19.687Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 38357
File: apps/meteor/app/apps/server/converters/departments.ts:59-70
Timestamp: 2026-03-18T22:07:19.687Z
Learning: In `apps/meteor/app/apps/server/converters/departments.ts`, the `convertAppDepartment` method uses non-null assertions (`!`) on `department.name`, `department.email`, and `department.offlineMessageChannelName` when constructing `newDepartment: ILivechatDepartment`. These fields are optional on `IAppsDepartment`, but the App framework flow guarantees their presence at the call site. Do not flag these non-null assertions as unsafe during code review.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-03-11T16:46:55.955Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39535
File: apps/meteor/app/apps/server/bridges/livechat.ts:249-249
Timestamp: 2026-03-11T16:46:55.955Z
Learning: In `apps/meteor/app/apps/server/bridges/livechat.ts`, `createVisitor()` intentionally does not propagate `externalIds` to `registerData`. This is by design: the method is deprecated (JSDoc: `deprecated Use createAndReturnVisitor instead. Note: This method does not support externalIds.`) to push callers toward `createAndReturnVisitor()`, which does support `externalIds`. Do not flag the missing `externalIds` field in `createVisitor()` as a bug.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 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:
apps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-03-16T11:50:18.066Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39657
File: apps/meteor/tests/end-to-end/apps/app-resolve-visitor.ts:18-21
Timestamp: 2026-03-16T11:50:18.066Z
Learning: In `apps/meteor/tests/end-to-end/apps/` (and Livechat E2E tests broadly), calling `createAgent()` and `makeAgentAvailable()` immediately after `updateSetting('Livechat_enabled', true)` — without any intermediate sleep — is an established, non-flaky pattern used across 10+ tests in the codebase. Do not flag this sequence as a potential race condition or suggest adding a delay between them.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-11T22:04:20.529Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 39545
File: apps/meteor/client/views/room/body/hooks/useHasNewMessages.ts:59-61
Timestamp: 2026-03-11T22:04:20.529Z
Learning: In `apps/meteor/client/views/room/body/hooks/useHasNewMessages.ts`, the `msg.u._id === uid` early-return in the `streamNewMessage` handler is intentional: the "New messages" indicator is designed to notify about messages from other users only. Self-sent messages — including those sent from a different session/device — are always skipped, by design. Do not flag this as a multi-session regression.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-20T13:51:23.302Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts:179-181
Timestamp: 2026-03-20T13:51:23.302Z
Learning: In `apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts`, the truthiness guards `...(integration.avatar && { avatar })`, `...(integration.emoji && { emoji })`, `...(integration.alias && { alias })`, and `...(integration.script && { script })` in the `$set` payload of `updateIncomingIntegration` are intentional. Empty-string values for these fields should NOT overwrite the stored value — only truthy values are persisted. Do not flag these as bugs preventing explicit clears.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-03-31T23:29:12.037Z
Learnt from: nazabucciarelli
Repo: RocketChat/Rocket.Chat PR: 39905
File: packages/models/src/models/LivechatVisitors.ts:391-406
Timestamp: 2026-03-31T23:29:12.037Z
Learning: In `packages/models/src/models/LivechatVisitors.ts`, `saveGuestEmailPhoneById` uses a two-step approach: (1) a `{ visitorEmails: null }` / `{ phone: null }` guard to lazily initialize legacy null fields to empty arrays (concurrency-safe: subsequent concurrent calls simply skip the no-match), then (2) `$addToSet` with `$each` to append without reordering. This is intentional and correct. Do not flag concurrency or ordering concerns: `visitorEmails[0]` is the primary email set during visitor registration and is never displaced by `$addToSet`; the `leadCapture` hook is a data-scraping bucket where entry order is irrelevant to business logic.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-15T14:31:28.969Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
apps/meteor/app/livechat/server/lib/Helper.tspackages/omni-core/src/visitor/create.tsapps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2025-12-18T15:18:31.688Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 37773
File: apps/meteor/client/views/mediaCallHistory/MediaCallHistoryInternal.tsx:24-34
Timestamp: 2025-12-18T15:18:31.688Z
Learning: In apps/meteor/client/views/mediaCallHistory/MediaCallHistoryInternal.tsx, for internal call history items, the item.contactId is guaranteed to always match either the caller.id or callee.id in the call data, so the contact resolution in getContact will never result in undefined.
Applied to files:
packages/omni-core/src/visitor/create.ts
📚 Learning: 2026-03-11T15:56:18.579Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39535
File: apps/meteor/client/views/omnichannel/directory/components/ContactField.tsx:40-46
Timestamp: 2026-03-11T15:56:18.579Z
Learning: In `apps/meteor/client/views/omnichannel/directory/components/ContactField.tsx`, `shortName` is intentionally built from the visitor's internal `username` and `phone` (not from `externalIds`). `ContactField` shows the visitor's internal system identifier. Per-channel external identifiers (e.g. WhatsApp usernames from `externalIds[].username`) are only displayed in `ContactInfoChannelsItem`, which serves a different UI context.
Applied to files:
packages/omni-core/src/visitor/create.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:
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2026-03-02T16:31:41.304Z
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 39250
File: apps/meteor/tests/end-to-end/api/livechat/07-queue.ts:1084-1094
Timestamp: 2026-03-02T16:31:41.304Z
Learning: In E2E API tests at apps/meteor/tests/end-to-end/api/livechat/, using sleep(1000) after updateSetting() or updateEESetting() calls in test setup hooks is acceptable and intentional to allow omnichannel settings to propagate their side effects.
Applied to files:
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
📚 Learning: 2025-11-27T17:56:26.050Z
Learnt from: MartinSchoeler
Repo: RocketChat/Rocket.Chat PR: 37557
File: apps/meteor/client/views/admin/ABAC/AdminABACRooms.tsx:115-116
Timestamp: 2025-11-27T17:56:26.050Z
Learning: In Rocket.Chat, the GET /v1/abac/rooms endpoint (implemented in ee/packages/abac/src/index.ts) only returns rooms where abacAttributes exists and is not an empty array (query: { abacAttributes: { $exists: true, $ne: [] } }). Therefore, in components consuming this endpoint (like AdminABACRooms.tsx), room.abacAttributes is guaranteed to be defined for all returned rooms, and optional chaining before calling array methods like .join() is sufficient without additional null coalescing.
Applied to files:
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts
🔇 Additional comments (5)
packages/omni-core/src/visitor/create.ts (2)
43-45: LGTM — argument order matches the updatedfindOneOnlineAgentByIdsignature.Threading
shouldConsiderIdleAgentandshouldConsiderOfflineAgentin positions 2 and 3 aligns withpackages/models/src/models/Users.ts(id, isLivechatEnabledWhenAgentIdle?, acceptChatsWithNoAgents?, options?).
20-20: AllregisterGuestcall sites correctly pass both required options.Verified across all production callers: REST endpoints (visitor, message), Apps bridge, livechat library, email inbox, and test suite. All pass both
shouldConsiderIdleAgentandshouldConsiderOfflineAgentoptions fetched from their respective settings.apps/meteor/app/livechat/server/lib/Helper.ts (2)
665-670: LGTM — signature and argument order match.
findOneOnlineAgentById(agentId, isLivechatEnabledWhenAgentIdle, acceptChatsWithNoAgents, options)is consistent withpackages/models/src/models/Users.ts:1914-1923.
499-511: This behavior change is intentional—no fix required.The setting
Livechat_accept_chats_with_no_agents, when enabled, is designed to remove the offline-status filter from agent lookups workspace-wide. The implementation inpackages/models/src/helpers/omnichannel/agentStatus.tsexplicitly omits the$oroffline-status guard whenacceptChatsWithNoAgents=true, allowing offline agents to be returned.This applies to both automatic routing and manual selection equally (per Omnichannel Admins guide), so manual forwards to offline agents succeeding under this setting is expected behavior, not a bug. The concern about "ghost agent" scenarios is valid as a UX/design consideration, but it is not a code issue—the setting is functioning as designed.
apps/meteor/ee/app/livechat-enterprise/server/hooks/handleNextAgentPreferredEvents.ts (1)
47-53: LGTM —findOneOnlineAgentByUserListcall aligns with its signature.Positional order
(userList, options, isLivechatEnabledWhenAgentIdle, acceptChatsWithNoAgents)matchespackages/models/src/models/Users.ts:1649-1663. Note this differs fromfindOneOnlineAgentById, whereoptionscomes last — a correctness-sensitive asymmetry worth keeping in mind for future callers but handled correctly here.Also applies to: 135-142
nazabucciarelli
commented
Apr 16, 2026
| return normalizeDefaultAgent(agent); | ||
| } | ||
|
|
||
| const offlineAgent = await Users.findOneAgentById(id, { projection: { _id: 1, username: 1 } }); |
Contributor
Author
There was a problem hiding this comment.
This code from line 38 to 41 seems redundant now that we filter out offline agents directly in the query. A task was created to evaluate its behavior and remove it if not needed: https://rocketchat.atlassian.net/browse/CORE-2122
ggazzo
approved these changes
Apr 17, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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)
The changes made in this PR were done following product team given directives.
acceptChatsWithNoAgentsto methods that fetch available agents. It basically passes the value of theLivechat_enabled_when_agent_offlinesetting downstream, to be able to process it and resolve offline agents to the visitor in case its value is true. This was made since after fixing the query, I've found out thatLivechat_enabled_when_agent_offlinewasn't being respected, and previously it "worked" (and note the quotation marks) because our query wasn't filtering out offline users at all.Issue(s)
CORE-1972 Fix 'Livechat_accept_chats_with_no_agents' omnichannel setting not being respected
Steps to test or reproduce
Before testing, you'd need to have a EE license and to create at least two agents and a department with them. Also, you'll need to go to Settings -> Omnichannel -> Queue Management, enable the Waiting queue option and then set Max. number of simultaneous chats to only 1.
Livechat_accept_chats_with_no_agentsis enabled, the new visitor isn't queued, but routed to the offline agent.Livechat_accept_chats_with_no_agentssetting.Further comments
Summary by CodeRabbit