fix: add offset and count pagination params support for chat.getMessageReadReceipts - #41720
Open
tejaswiverma121-byte wants to merge 1 commit into
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: 8f00823 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 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
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (2)
📜 Recent review details🧰 Additional context used📓 Path-based instructions (2)**/*.{ts,tsx,js}📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
Files:
apps/meteor/**📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (5)📚 Learning: 2026-02-26T19:25:44.063ZApplied to files:
📚 Learning: 2026-02-26T19:25:44.063ZApplied to files:
📚 Learning: 2026-05-06T12:21:44.083ZApplied to files:
📚 Learning: 2026-07-31T00:32:03.839ZApplied to files:
📚 Learning: 2026-07-31T02:44:35.111ZApplied to files:
🔇 Additional comments (4)
WalkthroughThe read-receipts endpoint now accepts optional ChangesRead-receipts pagination
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant ChatAPI
participant getReadReceiptsFunction
participant ReadReceipt
Client->>ChatAPI: Request receipts with offset and count
ChatAPI->>getReadReceiptsFunction: Forward messageId and pagination options
getReadReceiptsFunction->>ReadReceipt: Retrieve paginated receipts
ReadReceipt-->>getReadReceiptsFunction: Return sliced receipt list
getReadReceiptsFunction-->>ChatAPI: Return receipt data
ChatAPI-->>Client: Return receipts response
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
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 |
![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: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ui-client/src/components/GenericMenu/GenericMenu.tsx (1)
57-59: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winKeep custom triggers disabled when the menu is empty.
When
isMenuEmptyis true anddisabledis false or undefined, this branch passes that value tocloneElement. The custom trigger remains enabled even though no menu is rendered. Setdisabled: truefor this branch and add a regression test for an empty menu with a custombutton.Proposed fix
- return cloneElement(button, { small: true, icon, disabled, title, className } as any); + return cloneElement(button, { small: true, icon, disabled: true, title, className } as any);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui-client/src/components/GenericMenu/GenericMenu.tsx` around lines 57 - 59, Update the custom trigger handling in GenericMenu so the cloneElement call always passes disabled: true when isMenuEmpty is true, regardless of the incoming disabled value; preserve the existing disabled behavior for non-empty menus and add a regression test covering an empty menu with a custom button.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/rest-typings/src/v1/chat.ts`:
- Around line 490-508: The ChatGetMessageReadReceipts and
GetMessageReadReceiptsProps request contracts must match the runtime validator,
which rejects PaginatedRequest’s sort and query fields. In
packages/rest-typings/src/v1/chat.ts lines 490-508, and
apps/meteor/ee/server/api/chat.ts lines 15-17, constrain both types to
messageId, offset, and count, unless the runtime schema is intentionally
expanded to support sort and query; keep both definitions consistent.
---
Outside diff comments:
In `@packages/ui-client/src/components/GenericMenu/GenericMenu.tsx`:
- Around line 57-59: Update the custom trigger handling in GenericMenu so the
cloneElement call always passes disabled: true when isMenuEmpty is true,
regardless of the incoming disabled value; preserve the existing disabled
behavior for non-empty menus and add a regression test covering an empty menu
with a custom button.
🪄 Autofix
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 Plus
Run ID: af6b257c-75a9-4c1f-9f5f-68b2dee8adad
📒 Files selected for processing (6)
.changeset/chat-getmessagereadreceipts-pagination-params.md.changeset/deprecate-genericmenu-button-prop.mdapps/meteor/ee/server/api/chat.tsapps/meteor/tests/end-to-end/api/chat.tspackages/rest-typings/src/v1/chat.tspackages/ui-client/src/components/GenericMenu/GenericMenu.tsx
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: cubic · AI code reviewer
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{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/tests/end-to-end/api/chat.tspackages/ui-client/src/components/GenericMenu/GenericMenu.tsxapps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
apps/meteor/**
📄 CodeRabbit inference engine (CLAUDE.md)
The main Rocket.Chat Meteor application resides in
apps/meteor/; place its application code there rather than in other monorepo areas.
Files:
apps/meteor/tests/end-to-end/api/chat.tsapps/meteor/ee/server/api/chat.ts
packages/**
📄 CodeRabbit inference engine (CLAUDE.md)
Shared libraries belong in
packages/, while other services belong inapps/andee/.
Files:
packages/ui-client/src/components/GenericMenu/GenericMenu.tsxpackages/rest-typings/src/v1/chat.ts
🧠 Learnings (8)
📚 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/deprecate-genericmenu-button-prop.md.changeset/chat-getmessagereadreceipts-pagination-params.md
📚 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/tests/end-to-end/api/chat.tsapps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.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/tests/end-to-end/api/chat.tsapps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
📚 Learning: 2026-05-06T12:21:44.083Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.
Applied to files:
apps/meteor/tests/end-to-end/api/chat.tspackages/ui-client/src/components/GenericMenu/GenericMenu.tsxapps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
📚 Learning: 2026-03-27T14:52:56.865Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39892
File: apps/meteor/client/views/room/contextualBar/Threads/Thread.tsx:150-155
Timestamp: 2026-03-27T14:52:56.865Z
Learning: In Rocket.Chat, there are two different `ModalBackdrop` components with different prop APIs. During review, confirm the import source: (1) `rocket.chat/fuselage` `ModalBackdrop` uses `ModalBackdropProps` based on `BoxProps` (so it supports `onClick` and other Box/DOM props) and does not have an `onDismiss` prop; (2) `rocket.chat/ui-client` `ModalBackdrop` uses a narrower props interface like `{ children?: ReactNode; onDismiss?: () => void }` and handles Escape keypress and outside mouse-up, and it does not forward arbitrary DOM props such as `onClick`. Flag mismatched props (e.g., `onDismiss` passed to the fuselage component or `onClick` passed to the ui-client component) and ensure the usage matches the correct component being imported.
Applied to files:
packages/ui-client/src/components/GenericMenu/GenericMenu.tsx
📚 Learning: 2026-07-31T00:32:03.839Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 41635
File: apps/meteor/ee/server/api/roles.ts:101-111
Timestamp: 2026-07-31T00:32:03.839Z
Learning: In Rocket.Chat's typed EE REST API routes that use apps/meteor/ee/server/api/v1/middlewares/license.ts, account for unavailable route-level license modules returning HTTP 400 with { success: false, error, errorType: 'error-action-not-allowed' }, not HTTP 403. Declare the existing 400 bad-request response schema for these routes.
Applied to files:
apps/meteor/ee/server/api/chat.ts
📚 Learning: 2026-07-31T02:44:35.111Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 41635
File: apps/meteor/ee/server/api/sessions.ts:114-138
Timestamp: 2026-07-31T02:44:35.111Z
Learning: In Rocket.Chat typed REST response schemas, accept the composition of a Typia-generated entity schema with an `allOf` branch requiring `success: true`: `allOf: [{ $ref: <entity schema> }, { properties: { success: { type: 'boolean', enum: [true] } }, required: ['success'] }]`. Do not flag this pattern when used for REST endpoints, provided TEST_MODE response validation passes, as demonstrated by the `IOAuthApps` and `IEmailInbox` endpoints.
Applied to files:
apps/meteor/ee/server/api/chat.ts
📚 Learning: 2026-05-11T23:14:59.316Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 40469
File: packages/rest-typings/src/v1/users.ts:337-337
Timestamp: 2026-05-11T23:14:59.316Z
Learning: In Rocket.Chat REST endpoint typings (e.g., packages/rest-typings/src/v1/users.ts and other rest-typings files), keep the established convention of deriving field types from the domain model (e.g., use IUser indexed access like IUser['statusExpiresAt']) rather than swapping individual fields to serialized primitives (like string) in an ad-hoc way. If a truly different “serialized” representation is needed, perform the refactor consistently across the codebase (not just a single endpoint/field) and ensure all related REST typings stay aligned with the shared serialization types.
Applied to files:
packages/rest-typings/src/v1/chat.ts
🔇 Additional comments (4)
apps/meteor/tests/end-to-end/api/chat.ts (1)
2993-3014: LGTM!.changeset/chat-getmessagereadreceipts-pagination-params.md (1)
1-6: LGTM!packages/ui-client/src/components/GenericMenu/GenericMenu.tsx (1)
2-2: LGTM!Also applies to: 31-38
.changeset/deprecate-genericmenu-button-prop.md (1)
1-5: LGTM!
tejaswiverma121-byte
force-pushed
the
fix/chat-getMessageReadReceipts-pagination
branch
from
August 8, 2026 09:13
86a3b6c to
ef223a9
Compare
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
1 issue found and verified against the latest diff
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/tests/end-to-end/api/chat.ts">
<violation number="1" location="apps/meteor/tests/end-to-end/api/chat.ts:3010">
P2: This test only asserts HTTP 200 and that `receipts` is an array, so it would pass even if the server ignored `offset`/`count` entirely — which it currently does (the endpoint action destructures only `messageId` and calls `getReadReceiptsFunction(messageId, this.userId)` with no pagination applied). It therefore provides no coverage of the pagination behavior this PR claims to add. Consider verifying actual pagination, e.g. assert that a request with `count` returns at most `count` receipts and that `offset` shifts the returned window.</violation>
</file>
Tip: cubic used a learning from your PR history. Let your coding agent read cubic learnings directly with the cubic MCP.
Re-trigger cubic
| .expect('Content-Type', 'application/json') | ||
| .expect(200) | ||
| .expect((res) => { | ||
| expect(res.body).to.have.property('receipts').and.to.be.an('array'); |
Contributor
There was a problem hiding this comment.
P2: This test only asserts HTTP 200 and that receipts is an array, so it would pass even if the server ignored offset/count entirely — which it currently does (the endpoint action destructures only messageId and calls getReadReceiptsFunction(messageId, this.userId) with no pagination applied). It therefore provides no coverage of the pagination behavior this PR claims to add. Consider verifying actual pagination, e.g. assert that a request with count returns at most count receipts and that offset shifts the returned window.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/meteor/tests/end-to-end/api/chat.ts, line 3010:
<comment>This test only asserts HTTP 200 and that `receipts` is an array, so it would pass even if the server ignored `offset`/`count` entirely — which it currently does (the endpoint action destructures only `messageId` and calls `getReadReceiptsFunction(messageId, this.userId)` with no pagination applied). It therefore provides no coverage of the pagination behavior this PR claims to add. Consider verifying actual pagination, e.g. assert that a request with `count` returns at most `count` receipts and that `offset` shifts the returned window.</comment>
<file context>
@@ -2990,6 +2990,28 @@ describe('[Chat]', () => {
+ .expect('Content-Type', 'application/json')
+ .expect(200)
+ .expect((res) => {
+ expect(res.body).to.have.property('receipts').and.to.be.an('array');
+ expect(res.body).to.have.property('success', true);
+ })
</file context>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/meteor/ee/server/api/chat.ts`:
- Around line 16-17: Forward the request’s offset and count through the
read-receipts handler and retrieval call in
apps/meteor/ee/server/api/chat.ts#L16-L17, preserving pagination semantics end
to end. Retain the public offset/count fields in
packages/rest-typings/src/v1/chat.ts#L492-L493 only with that server
implementation; otherwise remove them from both contracts. Add or update the
end-to-end test to assert paginated results.
In `@packages/rest-typings/src/v1/chat.ts`:
- Around line 502-513: The ChatGetMessageReadReceiptsSchema pagination fields
offset and count currently accept invalid fractional and negative values. Update
both fields to require non-negative integers, and add validation cases covering
fractional and negative inputs while preserving valid pagination behavior.
🪄 Autofix
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 Plus
Run ID: ce95c761-b154-43b8-b3f6-0fd4ea403242
📒 Files selected for processing (2)
apps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{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/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
apps/meteor/**
📄 CodeRabbit inference engine (CLAUDE.md)
The main Rocket.Chat Meteor application resides in
apps/meteor/; place its application code there rather than in other monorepo areas.
Files:
apps/meteor/ee/server/api/chat.ts
packages/**
📄 CodeRabbit inference engine (CLAUDE.md)
Shared libraries belong in
packages/, while other services belong inapps/andee/.
Files:
packages/rest-typings/src/v1/chat.ts
🧠 Learnings (6)
📚 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/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.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/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
📚 Learning: 2026-05-06T12:21:44.083Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.
Applied to files:
apps/meteor/ee/server/api/chat.tspackages/rest-typings/src/v1/chat.ts
📚 Learning: 2026-07-31T00:32:03.839Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 41635
File: apps/meteor/ee/server/api/roles.ts:101-111
Timestamp: 2026-07-31T00:32:03.839Z
Learning: In Rocket.Chat's typed EE REST API routes that use apps/meteor/ee/server/api/v1/middlewares/license.ts, account for unavailable route-level license modules returning HTTP 400 with { success: false, error, errorType: 'error-action-not-allowed' }, not HTTP 403. Declare the existing 400 bad-request response schema for these routes.
Applied to files:
apps/meteor/ee/server/api/chat.ts
📚 Learning: 2026-07-31T02:44:35.111Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 41635
File: apps/meteor/ee/server/api/sessions.ts:114-138
Timestamp: 2026-07-31T02:44:35.111Z
Learning: In Rocket.Chat typed REST response schemas, accept the composition of a Typia-generated entity schema with an `allOf` branch requiring `success: true`: `allOf: [{ $ref: <entity schema> }, { properties: { success: { type: 'boolean', enum: [true] } }, required: ['success'] }]`. Do not flag this pattern when used for REST endpoints, provided TEST_MODE response validation passes, as demonstrated by the `IOAuthApps` and `IEmailInbox` endpoints.
Applied to files:
apps/meteor/ee/server/api/chat.ts
📚 Learning: 2026-05-11T23:14:59.316Z
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 40469
File: packages/rest-typings/src/v1/users.ts:337-337
Timestamp: 2026-05-11T23:14:59.316Z
Learning: In Rocket.Chat REST endpoint typings (e.g., packages/rest-typings/src/v1/users.ts and other rest-typings files), keep the established convention of deriving field types from the domain model (e.g., use IUser indexed access like IUser['statusExpiresAt']) rather than swapping individual fields to serialized primitives (like string) in an ad-hoc way. If a truly different “serialized” representation is needed, perform the refactor consistently across the codebase (not just a single endpoint/field) and ensure all related REST typings stay aligned with the shared serialization types.
Applied to files:
packages/rest-typings/src/v1/chat.ts
tejaswiverma121-byte
force-pushed
the
fix/chat-getMessageReadReceipts-pagination
branch
from
August 8, 2026 09:25
ef223a9 to
8f00823
Compare
Contributor
|
@tejaswiverma121-byte I had opened #41723 with essentially this same change before noticing yours - closing it, since you were here first. Two details from it that may be worth folding in:
Both are small; feel free to take or ignore. |
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
2 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)
Issue(s)
Steps to test or reproduce
Further comments
Proposed changes (including videos or screenshots)
offsetandcountpagination query parameters toChatGetMessageReadReceiptsSchemaand updatedChatGetMessageReadReceiptsto extendPaginatedRequestin@rocket.chat/rest-typings.isChatGetMessageReadReceiptsPropsfromajv.compiletoajvQuery.compileto properly coerce query string parameters (e.g."0"and"10") to numbers.GetMessageReadReceiptsPropsinapps/meteor/ee/server/api/chat.tsto extendPaginatedRequest.apps/meteor/tests/end-to-end/api/chat.tsensuring requests withoffsetandcountquery parameters return200 OK..changeset/chat-getmessagereadreceipts-pagination-params.md.Issue(s)
Closes #41719
Steps to test or reproduce
GETrequest to/api/v1/chat.getMessageReadReceiptspassingmessageId,offset, andcountquery parameters:Summary by CodeRabbit
Bug Fixes
chat.getMessageReadReceiptsrequests using pagination parameters.countandoffsetvalues while continuing to require a message ID.Tests