chore: Implement user caching for publication access#39667
Open
chore: Implement user caching for publication access#39667
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 |
|
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent 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). (3)
WalkthroughAdds a per-publication cached user lookup (getCachedUserForPublication) and integrates it into notifications stream handlers to replace direct this.userId checks; also evicts cached publication users on user updates via the Meteor service watch.users handler (invalidatePublicationUserCache). Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Publication as Publication/Stream
participant Cache as PublicationUserCache
participant Auth as Authorization
participant DB as UsersDB
participant Service as MeteorService
Client->>Publication: subscribe / trigger stream handler
Publication->>Cache: getCachedUserForPublication(publication)
alt cache hit
Cache-->>Publication: user { _id, roles }
else cache miss
Cache->>DB: Users.findOneById(userId, projection)
DB-->>Cache: user { _id, roles } or null
Cache-->>Publication: user or null
end
Publication->>Auth: Authorization checks (canReadRoom / canAccessRoom / perms) with user
Auth-->>Publication: allow / deny
Publication-->>Client: publish data or stop
Note over Service,Cache: On user update
Service->>Cache: invalidatePublicationUserCache(userId)
Cache-->>Cache: remove cached entry / clear timer
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
🚥 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. Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
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. Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.Comment |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #39667 +/- ##
===========================================
- Coverage 69.86% 69.84% -0.02%
===========================================
Files 3298 3299 +1
Lines 119347 119372 +25
Branches 21530 21521 -9
===========================================
- Hits 83377 83375 -2
- Misses 32672 32689 +17
- Partials 3298 3308 +10
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}
Contributor
There was a problem hiding this comment.
2 issues found across 3 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="apps/meteor/server/services/meteor/service.ts">
<violation number="1" location="apps/meteor/server/services/meteor/service.ts:82">
P2: This adds every updated user ID to a global Set that is never evicted unless that user reads a cached publication again.</violation>
</file>
<file name="apps/meteor/server/modules/streamer/publication-user-cache.ts">
<violation number="1" location="apps/meteor/server/modules/streamer/publication-user-cache.ts:26">
P1: Clearing the invalidation flag after refreshing one publication leaves other publications for the same user on stale authorization data.
(Based on your team's feedback about questioning concurrency-related behavioral changes.) [FEEDBACK_USED]</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Member
Author
|
/jira ARCH-2021 |
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/meteor/server/modules/streamer/publication-user-cache.ts`:
- Around line 38-40: invalidate(userId) currently deletes the cache entry but
leaves any previously scheduled eviction timer active; update invalidate to
first clear the active timeout for that user (use clearTimeout on the timer
stored for that user in whatever timers map you maintain—e.g.,
timeoutByUser/evictionTimeouts), remove the timer entry from that map, then
delete the entry from cacheByPublication so a stale callback cannot evict a
newly refreshed cache item; ensure you reference the same timer storage used
when scheduling evictions and remove its entry after clearing.
- Around line 16-34: The cache currently races with in-flight Users.findOneById
calls and can reinsert stale data; to fix, introduce a per-user generation token
or store the pending promise in cacheByPublication so invalidation wins: when
reading, check cacheByPublication.get(userId) and if a pending promise exists
await it; when starting a new Users.findOneById, create and store a pending
entry (with a generation or promise) before awaiting; on invalidation
(watch.users) increment the user's generation or delete the cache entry so any
late resolution is discarded by comparing generation tokens or by replacing the
pending promise check, and only set the final user + timeout into
cacheByPublication if the stored token/promise still matches the one created for
this lookup (use existing symbols cacheByPublication, Users.findOneById,
CACHE_TIMEOUT, CACHE_PROJECTION).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cef27f0e-7ceb-4600-84fc-cf03dce30709
📒 Files selected for processing (1)
apps/meteor/server/modules/streamer/publication-user-cache.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). (3)
- GitHub Check: 📦 Build Packages
- GitHub Check: CodeQL-Build
- 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/server/modules/streamer/publication-user-cache.ts
🧠 Learnings (14)
📓 Common learnings
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.
📚 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:
apps/meteor/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-30T14:57:42.623Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 40185
File: packages/apps/deno-runtime/lib/room.ts:45-45
Timestamp: 2026-04-30T14:57:42.623Z
Learning: In `packages/apps/deno-runtime/lib/room.ts`, the `getUsernames()` method intentionally uses `await` before assigning the result to `this._USERNAMES` (typed as `Promise<Array<string>> | undefined`), storing the resolved `Array<string>` rather than the Promise. This is a deliberate backward-compatibility workaround with the existing API and should not be flagged as a type mismatch or cache-contract violation in future reviews.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-18T12:32:53.425Z
Learnt from: rodrigok
Repo: RocketChat/Rocket.Chat PR: 38623
File: apps/meteor/app/lib/server/functions/cleanRoomHistory.ts:146-149
Timestamp: 2026-04-18T12:32:53.425Z
Learning: In `apps/meteor/app/lib/server/functions/cleanRoomHistory.ts` (PR `#38623`), the read-receipt cleanup (both `ReadReceipts.removeByMessageIds` and `ReadReceiptsArchive.removeByMessageIds`) is intentionally only performed in the limited prune path (`limit && selectedMessageIds`). The unlimited/delete-all path (`limit === 0`) deliberately skips cleaning up orphaned read receipts in both hot and cold storage — this is by design. Do not flag this as a bug or missing cleanup in future reviews.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-29T19:33:29.434Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 40268
File: apps/meteor/client/startup/startup.ts:48-56
Timestamp: 2026-04-29T19:33:29.434Z
Learning: In `apps/meteor/client/startup/startup.ts`, the heuristic `!userIdStore.getState() && localStorage.getItem('Meteor.loginToken') === null` calling `removeLocalUserData()` (which calls `localStorage.clear()`) is intentional. The maintainer (tassoevan) has confirmed this is acceptable even though it fires on fresh first-time visits with no prior login, not just on expired-token resume scenarios. Do not flag this as destructive or suggest narrowing it to specific E2EE keys in future reviews.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-29T20:06:34.862Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 40268
File: apps/meteor/client/startup/incomingMessages.ts:21-25
Timestamp: 2026-04-29T20:06:34.862Z
Learning: In `apps/meteor/client/startup/incomingMessages.ts`, the `Messages.state.update` predicate that strips `ignored` from records when `'ignored' in sub` is false (i.e., the subscription update has no `ignored` field) is intentional. Absence of `ignored` in a `subscriptions-changed` event means the user's ignore list is empty/reset, so clearing all existing `ignored` flags on messages for that room is the correct behavior. Do not flag this as an unintentional ignored-state reset on unrelated subscription updates.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.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/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-10T21:17:22.932Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 40096
File: apps/meteor/ee/server/apps/lib/redactor.ts:3-17
Timestamp: 2026-04-10T21:17:22.932Z
Learning: In RocketChat/Rocket.Chat, `X-User-Id` / `x-user-id` headers must NOT be added to redaction paths in apps log redaction (e.g., `apps/meteor/ee/server/apps/lib/redactor.ts`). The maintainer (d-gubert) has confirmed that X-User-Id is an identifier, not a credential — its presence in logs is useful for diagnostics, and `X-Auth-Token` is the only header that constitutes a real secret. Do not suggest redacting X-User-Id in future reviews of this area.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.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/modules/streamer/publication-user-cache.ts
📚 Learning: 2026-04-20T17:11:59.452Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 40225
File: apps/meteor/ee/server/apps/communication/endpoints/appLogsHandler.ts:55-71
Timestamp: 2026-04-20T17:11:59.452Z
Learning: In `apps/meteor/ee/server/apps/communication/endpoints/appLogsHandler.ts`, the concern about an empty `?appId=` query param bypassing the truthy check and overriding the path `appId` in the `makeAppLogsQuery` spread is not relevant. The AJV query schema (`isAppLogsProps`) validates and rejects invalid/empty `appId` values before the action handler is reached, making the in-handler guard sufficient as-is. Do not flag this pattern as a vulnerability in future reviews of this file.
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.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/server/modules/streamer/publication-user-cache.ts
📚 Learning: 2025-12-09T20:01:07.355Z
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>
Applied to files:
apps/meteor/server/modules/streamer/publication-user-cache.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/server/modules/streamer/publication-user-cache.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/server/modules/streamer/publication-user-cache.ts
…ent in publication access
…roved user data handling
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
1 participant
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.
This pull request introduces a user caching mechanism for publication contexts in the notifications module, aiming to optimize repeated user lookups and improve performance. The main change is the addition of a cache layer for user data (specifically user ID and roles) that is used in permission and authorization checks throughout the notifications streaming system. The cache is automatically invalidated when user data changes, ensuring consistency.
Key changes include:
User Caching Implementation:
getCachedUserForPublicationinpublication-user-cache.tsto cache user objects (with_idandroles) per publication context for a short period, reducing repeated database queries.invalidatefunction to clear the cache for a user when their data changes.Integration with Notifications Module:
this.userIdwith calls togetCachedUserForPublicationthroughoutnotifications.module.ts, ensuring all permission and room access checks use the cached user object. This affects methods likeallowRead,allowEmit, and various authorization checks. [1] [2] [3] [4] [5] [6] [7] [8]Cache Invalidation on User Updates:
service.tsto callinvalidatePublicationUserCache, ensuring the cache is cleared when a user's data changes. [1] [2]These changes collectively improve the efficiency of user permission checks in the server's notification streaming logic while maintaining up-to-date authorization data.
Task: ARCH-2056
Summary by CodeRabbit
Performance
Reliability