feat(rest): migrate /api/v1/me to OpenAPI endpoint definition#39221
feat(rest): migrate /api/v1/me to OpenAPI endpoint definition#39221Yashika-code wants to merge 1 commit intoRocketChat:developfrom
Conversation
|
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 |
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughReplaces the inline /api/v1/me route with a named Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant API as API.v1.me
participant Auth as Auth Layer
participant Handler as action()
participant Service as getUserInfo
participant Validator as AJV
Client->>API: GET /api/v1/me
API->>Auth: verify token
Auth-->>API: authorized
API->>Handler: invoke action()
Handler->>Service: getUserInfo(user)
Service-->>Handler: userInfo
Handler->>Validator: validate 200 response (meResponseSchema)
Validator-->>API: validated response
API-->>Client: 200 OK (me response)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📝 Coding Plan
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 Tip You can generate walkthrough in a markdown collapsible section to save space.Enable the |
coderabbitai
Bot
added
the
type: feature
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/meteor/app/api/server/v1/misc.ts (1)
22-22: Useimport typefor type-only import.
ExtractRoutesFromAPIis only used in a type position (line 200). Using a type-only import ensures proper erasure at compile time and improves tree-shaking.♻️ Proposed fix
-import { ExtractRoutesFromAPI } from '../../../lib/rest/typings'; +import type { ExtractRoutesFromAPI } from '../../../lib/rest/typings';🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/app/api/server/v1/misc.ts` at line 22, The import of ExtractRoutesFromAPI is type-only and should be changed to a type-only import to ensure it is erased at compile time; update the import statement to use "import type { ExtractRoutesFromAPI } from '../../../lib/rest/typings';" so the symbol (ExtractRoutesFromAPI) is treated purely as a type and improves tree-shaking where it's used (e.g., in the type position around the route typing).
🤖 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/app/api/server/v1/misc.ts`:
- Line 198: The API.v1.get(...) call in misc.ts is closed with the wrong
delimiter ("};") causing a syntax error; open the API.v1.get invocation (look
for the API.v1.get function definition/closure) and replace the erroneous
closing "};" with the correct closing ");" so the call ends with a parenthesis
and semicolon, ensuring the function callback block (the handler) still ends
with its closing brace before that parenthesis.
---
Nitpick comments:
In `@apps/meteor/app/api/server/v1/misc.ts`:
- Line 22: The import of ExtractRoutesFromAPI is type-only and should be changed
to a type-only import to ensure it is erased at compile time; update the import
statement to use "import type { ExtractRoutesFromAPI } from
'../../../lib/rest/typings';" so the symbol (ExtractRoutesFromAPI) is treated
purely as a type and improves tree-shaking where it's used (e.g., in the type
position around the route typing).
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/meteor/app/api/server/v1/misc.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 (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/api/server/v1/misc.ts
🧠 Learnings (6)
📓 Common learnings
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.
📚 Learning: 2026-02-24T19:09:01.522Z
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:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.
Applied to files:
apps/meteor/app/api/server/v1/misc.ts
📚 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:
apps/meteor/app/api/server/v1/misc.ts
📚 Learning: 2026-02-23T17:53:06.802Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.
Applied to files:
apps/meteor/app/api/server/v1/misc.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/api/server/v1/misc.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/api/server/v1/misc.ts
🔇 Additional comments (2)
apps/meteor/app/api/server/v1/misc.ts (2)
200-204: LGTM!The type extraction and module augmentation follow the established pattern in this file and properly extend the
Endpointsinterface for the migrated endpoint.
192-197: LGTM!The handler preserves the original endpoint behavior while adopting the new structured route definition pattern. The type assertion is acceptable given
authRequired: trueensures the user context exists.
There was a problem hiding this comment.
🧹 Nitpick comments (2)
apps/meteor/app/api/server/v1/misc.ts (2)
22-22: Useimport typefor type-only import.
ExtractRoutesFromAPIis only used as a type on line 200. Using a value import may prevent tree-shaking and doesn't communicate intent.♻️ Suggested fix
-import { ExtractRoutesFromAPI } from '../../../lib/rest/typings'; +import type { ExtractRoutesFromAPI } from '../../../lib/rest/typings';🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/app/api/server/v1/misc.ts` at line 22, The import for ExtractRoutesFromAPI is a type-only import; change the statement to use a type-only import (e.g., import type { ExtractRoutesFromAPI } from '../../../lib/rest/typings') so the compiler/tree-shaker knows it's not a runtime value; update the import where ExtractRoutesFromAPI is referenced (used as a type around line 200) and ensure no runtime references to that symbol remain.
182-189: Response schema validates onlysuccessfield.The 200 response schema uses
additionalProperties: trueand only checks forsuccess: true, providing minimal runtime validation. The actual user data returned bygetUserInfo()isn't validated against the detailed OpenAPI spec in the JSDoc comment above.This may be intentional to keep migration scope tight, but consider whether stricter validation is desired for this endpoint.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/app/api/server/v1/misc.ts` around lines 182 - 189, The 200 response AJV schema currently only asserts success: true (in the ajv.compile block) and allows any other properties via additionalProperties: true; update that schema used by the getUserInfo() response to validate the full user payload described in the JSDoc by enumerating the expected properties (e.g., id, email, name, avatar, roles, createdAt, etc.), their types and required fields, and set additionalProperties: false (or explicitly allow known extras) so the runtime validation matches the OpenAPI/JSDoc contract; modify the ajv.compile call for the 200 response to include the full object schema instead of only success and run/adjust tests accordingly.
🤖 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/app/api/server/v1/misc.ts`:
- Line 22: The import for ExtractRoutesFromAPI is a type-only import; change the
statement to use a type-only import (e.g., import type { ExtractRoutesFromAPI }
from '../../../lib/rest/typings') so the compiler/tree-shaker knows it's not a
runtime value; update the import where ExtractRoutesFromAPI is referenced (used
as a type around line 200) and ensure no runtime references to that symbol
remain.
- Around line 182-189: The 200 response AJV schema currently only asserts
success: true (in the ajv.compile block) and allows any other properties via
additionalProperties: true; update that schema used by the getUserInfo()
response to validate the full user payload described in the JSDoc by enumerating
the expected properties (e.g., id, email, name, avatar, roles, createdAt, etc.),
their types and required fields, and set additionalProperties: false (or
explicitly allow known extras) so the runtime validation matches the
OpenAPI/JSDoc contract; modify the ajv.compile call for the 200 response to
include the full object schema instead of only success and run/adjust tests
accordingly.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/meteor/app/api/server/v1/misc.ts
📜 Review details
🧰 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/api/server/v1/misc.ts
🧠 Learnings (6)
📓 Common learnings
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.
📚 Learning: 2026-02-24T19:09:01.522Z
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:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.
Applied to files:
apps/meteor/app/api/server/v1/misc.ts
📚 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:
apps/meteor/app/api/server/v1/misc.ts
📚 Learning: 2026-02-23T17:53:06.802Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.
Applied to files:
apps/meteor/app/api/server/v1/misc.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/api/server/v1/misc.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/api/server/v1/misc.ts
🔇 Additional comments (2)
apps/meteor/app/api/server/v1/misc.ts (2)
200-204: LGTM!The type export and module augmentation correctly extend the
@rocket.chat/rest-typingsEndpoints interface with the newMeEndpointstype, following the OpenAPI migration pattern.
175-198: Migration follows OpenAPI endpoint pattern correctly.The endpoint definition uses
API.v1.get()with proper configuration forauthRequired, response validators, and the action handler. The implementation preserves existing behavior by reusinggetUserInfo().
There was a problem hiding this comment.
You've got the main idea for the project right! However, you also need to remove the logic from rest-typings. Additionally, there are a few minor updates needed regarding variable naming and import paths. Please review PR #36882 to see how we handle migrations, and if you have a question feel free to ask any time
I review this mentined PR , after this i update in my latest commit . Please review it , is there need of again any updation or not . |
coderabbitai
Bot
added
area: authentication
and removed
type: feature
ahmed-n-abdeltwab
left a comment
ahmed-n-abdeltwab
left a comment
There was a problem hiding this comment.
You still need to clean up the endpoint in the rest-typings at packages/rest-typings/src/v1/me.ts. Second, please remove the old @openapi block and create a detected schema and interface. like the PR that i previously mentioned
Hint: You can use the existing OpenAPI comment above the API as a reference to verify the fields and ensure nothing is forgotten
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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/app/api/server/v1/misc.ts">
<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:115">
P2: `meResponseSchema` requires `email`, but `getUserInfo` returns `email: undefined` when the user has no verified email. This can make valid `/api/v1/me` responses fail AJV validation at runtime.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/meteor/app/api/server/v1/misc.ts (1)
39-43: Drop the newly added section comments in implementation code.These two block comments are non-functional and can be removed to keep the migration diff focused.
As per coding guidelines: "Avoid code comments in the implementation".
Also applies to: 125-129
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/meteor/app/api/server/v1/misc.ts` around lines 39 - 43, Remove the non-functional block comments added in the implementation: delete the "/api/v1/me endpoint schema" comment block and the other block comment around lines 125-129 so the code contains no implementation comments; locate them in apps/meteor/app/api/server/v1/misc.ts by searching for the exact comment text "/api/v1/me endpoint schema" and the second block comment and remove those comment blocks only (leave surrounding code, function and export names intact).
🤖 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/app/api/server/v1/misc.ts`:
- Around line 66-67: The IUser type in misc.ts incorrectly declares customFields
as unknown[] which conflicts with core-typings (Record<string, any>) and causes
AJV validation to reject valid /me responses; update the declaration in misc.ts
(the IUser/interface where customFields is defined) to use a map type (e.g.,
Record<string, any> or Record<string, unknown>) instead of an array, and if
there is a local AJV/schema definition for customFields adjust it to accept an
object map rather than an array so runtime validation matches the core-typings.
---
Nitpick comments:
In `@apps/meteor/app/api/server/v1/misc.ts`:
- Around line 39-43: Remove the non-functional block comments added in the
implementation: delete the "/api/v1/me endpoint schema" comment block and the
other block comment around lines 125-129 so the code contains no implementation
comments; locate them in apps/meteor/app/api/server/v1/misc.ts by searching for
the exact comment text "/api/v1/me endpoint schema" and the second block comment
and remove those comment blocks only (leave surrounding code, function and
export names intact).
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/meteor/app/api/server/v1/misc.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 (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/api/server/v1/misc.ts
🧠 Learnings (7)
📓 Common learnings
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.
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:18.785Z
Learning: In Rocket.Chat PR reviews, maintain strict scope boundaries—when a PR is focused on a specific endpoint (e.g., rooms.favorite), avoid reviewing or suggesting changes to other endpoints that were incidentally refactored (e.g., rooms.invite) unless explicitly requested by maintainers.
📚 Learning: 2026-02-24T19:09:01.522Z
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:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.
Applied to files:
apps/meteor/app/api/server/v1/misc.ts
📚 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:
apps/meteor/app/api/server/v1/misc.ts
📚 Learning: 2026-02-10T16:32:49.806Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 38528
File: apps/meteor/client/startup/roles.ts:14-14
Timestamp: 2026-02-10T16:32:49.806Z
Learning: In Rocket.Chat's Meteor client code, DDP streams use EJSON which automatically deserializes Date objects. Stream handlers (e.g., sdk.stream()) receive Date fields as Date objects directly and do not require manual conversion using `new Date()`. Only REST API responses require manual date conversion because they return plain JSON where dates are serialized as strings.
Applied to files:
apps/meteor/app/api/server/v1/misc.ts
📚 Learning: 2026-02-23T17:53:06.802Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.
Applied to files:
apps/meteor/app/api/server/v1/misc.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/api/server/v1/misc.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/api/server/v1/misc.ts
🔇 Additional comments (1)
apps/meteor/app/api/server/v1/misc.ts (1)
130-151: Migration structure for/api/v1/meis clean and aligned with OpenAPI rollout.Using
API.v1.get, explicit auth/response validators, extracted route typings, and module augmentation is a solid endpoint migration shape.
coderabbitai
Bot
added
type: feature
|
The main error during deployment is caused by packages/rest-typings/src/v1/me.ts. |
| 'me', | ||
| { | ||
| authRequired: true, | ||
| response: { | ||
| 401: validateUnauthorizedErrorResponse, | ||
| 200: ajv.compile<IMeResponse>(meResponseSchema), |
There was a problem hiding this comment.
We no longer manually define schemas for responses. Instead, we use Typia to generate them automatically. The file packages/core-typings/src/Ajv.ts serves as the single source of truth for the API's JSON schemas via $ref locations. However, I don't think the IUser interface has been added to Typia yet. To fix this, you will need to:
- Export IUser from packages/core-typings/src/IUser.ts inside packages/core-typings/src/Ajv.ts
- Add the interface to typia.json.schemas
- Build the project; the generated schema will then appear in packages/core-typings/dist/Ajv.js
You won't need to manually edit the generated file, but it's important to understand this flow so you can correctly use $ref: "#/components/schemas/IUser". For more context, please review PR #36882 and check the Typia documentation regarding JSON schema generation
There was a problem hiding this comment.
this file should be moved to apps/meteor/app/api/server/v1/misc.ts and remove from the packages/rest-typings
There was a problem hiding this comment.
I have tried to apply all these points in latest commits.
github-project-automation
Bot
moved this to Backlog
in rest api conversion to new endpoints
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
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/app/api/server/v1/misc.ts">
<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:49">
P2: Declared 200 response schema is `IUser`, but the handler returns `API.v1.success(...)` which adds `success: true` to the body, so the actual payload does not match the declared schema. This will misdocument the API and can break response validation/client generation.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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/app/api/server/v1/misc.ts">
<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:49">
P2: OpenAPI response schema declares raw IUser, but the handler returns API.v1.success(...), which adds a success envelope. The 200 schema should reflect the success wrapper to avoid mismatched validation/clients.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
We aren't just removing this; we also need to move the query schema to apps/meteor/app/api/server/v1/misc.ts. I've extracted these from this file. it wasn't located there, but you’ll need to figure it out how
type Keys =
| 'name'
| 'username'
| 'nickname'
| 'emails'
| 'status'
| 'statusDefault'
| 'statusText'
| 'statusConnection'
| 'bio'
| 'avatarOrigin'
| 'utcOffset'
| 'language'
| 'settings'
| 'idleTimeLimit'
| 'roles'
| 'active'
| 'defaultRoom'
| 'customFields'
| 'requirePasswordChange'
| 'requirePasswordChangeReason'
| 'services.github'
| 'services.gitlab'
| 'services.password.bcrypt'
| 'services.totp.enabled'
| 'services.email2fa.enabled'
| 'statusLivechat'
| 'banners'
| 'oauth.authorizedClients'
| '_updatedAt'
| 'avatarETag';
type MeParams = { fields: Record<Keys, 0> | Record<Keys, 1>; user: IUser }
const meSchema = {
type: 'object',
properties: {
},
additionalProperties: false,
required: ['fields', 'user'],
};
const isMeProps = ajv.compile<meParams>(MeSchema);additionally, here in the MeEndpoints type, the params property defines the required query parameters (for GET requests) or the request body (for POST requests). The type following the => arrow specifies exactly what the /v1/me endpoint returns. We use these definitions as our primary reference; the actual API implementation must be strictly matched to return these exact fields
export type MeEndpoints = {
'/v1/me': {
GET: (params?: { fields: Record<Keys, 0> | Record<Keys, 1>; user: IUser }) => IUser & {
email?: string;
settings?: {
profile: Record<string, unknown>;
preferences: unknown;
};
avatarUrl: string;
};
};
};
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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="packages/core-typings/src/Ajv.ts">
<violation number="1" location="packages/core-typings/src/Ajv.ts:14">
P1: Shared typings package now imports an app-layer source file, violating package boundaries and risking isolated build/project-reference failures.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
|
@ahmed-n-abdeltwab Could you please review new updates . |
| // AJV validation schema | ||
| const meSchema = { | ||
| type: 'object', | ||
| properties: {}, |
There was a problem hiding this comment.
You forgot to add the properties here
There was a problem hiding this comment.
yes, Now i update it
|
you need to testing locally and To do so, run the server as usual but with these parameters: TEST_MODE=true yarn dsv Then, open a new terminal, navigate to the apps/meteor directory, and run the following commands: # Test all Chat endpoints
cd apps/meteor
yarn testapi -f '[Chat]'
# Test specific endpoint
yarn testapi -f 'should create a direct message'
# Run all API tests
yarn testapiI recommend not running all API tests at once, as this can take a huge amount of time. also for scanning the code for typescript error you could use these commands too, i always run these before commits to make sure that everything is right and you are going to learn a lot from debugging and tracing the bugs. # Fix ESLint issues
yarn eslint:fix
# Fix Stylelint issues
yarn stylelint:fix
# Run all linters (no auto-fix)
yarn lint |
Tested locally ✅ |
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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/app/api/server/v1/misc.ts">
<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:66">
P2: `/me` response contract was narrowed to `{ success: true }`, losing explicit typing/schema for returned user data and causing schema/type drift.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| @@ -32,15 +32,10 @@ type Keys = | |||
| | '_updatedAt' | |||
| | 'avatarETag'; | |||
|
|
|||
| export type MeEndpoints = { | |||
| '/v1/me': { | |||
| GET: (params?: { fields: Record<Keys, 0> | Record<Keys, 1>; user: IUser }) => IUser & { | |||
| email?: string; | |||
| settings?: { | |||
| profile: Record<string, unknown>; | |||
| preferences: unknown; | |||
| }; | |||
| avatarUrl: string; | |||
| }; | |||
| }; | |||
| export interface IMeResponse extends IUser { | |||
| success: true; | |||
| } | |||
|
|
|||
| export type MeParams = { | |||
| fields?: Partial<Record<Keys, 0 | 1>>; | |||
There was a problem hiding this comment.
this's not right, take a look at this example #36916
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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/app/api/server/v1/misc.ts">
<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:73">
P2: `/me` response schema declares `email` as string, but runtime response can set `email` to `undefined`, causing schema/response drift and possible validation failures.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| name: { type: 'string' }, | ||
| username: { type: 'string' }, | ||
| nickname: { type: 'string' }, | ||
| email: { type: 'string' }, |
There was a problem hiding this comment.
P2: /me response schema declares email as string, but runtime response can set email to undefined, causing schema/response drift and possible validation failures.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/meteor/app/api/server/v1/misc.ts, line 73:
<comment>`/me` response schema declares `email` as string, but runtime response can set `email` to `undefined`, causing schema/response drift and possible validation failures.</comment>
<file context>
@@ -63,9 +63,28 @@ export const meEndpoints = API.v1.get(
+ name: { type: 'string' },
+ username: { type: 'string' },
+ nickname: { type: 'string' },
+ email: { type: 'string' },
+ status: { type: 'string' },
+ statusDefault: { type: 'string' },
</file context>
|
That doesn’t match the project description. Could you take a look at the description in this PR? RocketChat/Rocket.Chat-Open-API#150 |
|
Since getUserInfo() returns a spread of IUser with additional fields (email, avatarUrl, settings, isOAuthUser, services), and getBaseUserFields() doesn't project all required IUser fields like createdAt, using allOf with $ref: '#/components/schemas/IUser' causes a validation failure. |
There was a problem hiding this comment.
As you can see here, the /v1/me endpoint returns the IUser interface + an object with email, settings, and avatarUrl. We must implement a JSON schema to validate this response because the frontend code expects this specific structure. Changing the return format is not acceptable. The same requirement applies to the query JSON schema.
also you have to remove the /v1/me from the MeEndpoints that's in packages/rest-typings/src/v1/me.ts and move any old schema or validation to the apps/meteor/app/api/server/v1/misc.ts so we would have the file apps/meteor/app/api/server/v1/misc.ts that's contain everything about the /v1/me Endpoints
Using additionalProperties: true isn't ideal. We avoid it because it weakens validation and moves us away from our goal of creating clear documentation for the endpoints. you could debug getUserInfo to see why it isn't returning the expected data. Set a timer for this task so you don't spend too much time on it or you could move on something else. |
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
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=".changeset/migrate-users-getStatus-openapi.md">
<violation number="1" location=".changeset/migrate-users-getStatus-openapi.md:6">
P2: Changeset description references the wrong endpoint (`users.getStatus`), causing inaccurate release notes for a `/api/v1/me` migration.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| "@rocket.chat/rest-typings": patch | ||
| --- | ||
|
|
||
| Migrates the `users.getStatus` REST API endpoint from the legacy `API.v1.addRoute` pattern to the new chained `API.v1.get()` pattern with AJV response schema validation and OpenAPI documentation support. |
There was a problem hiding this comment.
P2: Changeset description references the wrong endpoint (users.getStatus), causing inaccurate release notes for a /api/v1/me migration.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .changeset/migrate-users-getStatus-openapi.md, line 6:
<comment>Changeset description references the wrong endpoint (`users.getStatus`), causing inaccurate release notes for a `/api/v1/me` migration.</comment>
<file context>
@@ -0,0 +1,6 @@
+"@rocket.chat/rest-typings": patch
+---
+
+Migrates the `users.getStatus` REST API endpoint from the legacy `API.v1.addRoute` pattern to the new chained `API.v1.get()` pattern with AJV response schema validation and OpenAPI documentation support.
</file context>
| Migrates the `users.getStatus` REST API endpoint from the legacy `API.v1.addRoute` pattern to the new chained `API.v1.get()` pattern with AJV response schema validation and OpenAPI documentation support. | |
| Migrates the `/api/v1/me` REST API endpoint from the legacy `API.v1.addRoute` pattern to the new chained `API.v1.get()` pattern with AJV response schema validation and OpenAPI documentation support. |
github-project-automation
Bot
moved this from Backlog
to Done
in rest api conversion to new endpoints
|
why? |
I accidentally closed the PR while syncing my fork with the upstream |
|
Hey @Yashika-code, thank you for your contribution! 🙏 This endpoint has already been migrated as part of #39553, which consolidated all OpenAPI migrations to make it easier to test and validate everything as a single unit. That PR has been merged into |
3 participants
Summary
This PR migrates the
/api/v1/meendpoint from the legacyAPI.v1.addRouteimplementation to the new OpenAPI-based endpoint definition pattern.Changes
API.v1.getExtractRoutesFromAPI@rocket.chat/rest-typingsEndpoints interfaceTesting
/api/v1/me/api/v1/meNotes
This is part of the incremental migration of legacy REST routes to the new OpenAPI architecture. This is part of REST endpoint migration initiative.
Summary by CodeRabbit