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 14 commits intoRocketChat:developfrom
Conversation
- Replace legacy API.v1.addRoute with API.v1.get - Add AJV response validation schema - Export MeEndpoints using ExtractRoutesFromAPI - Extend @rocket.chat/rest-typings Endpoints interface - Enable OpenAPI/Swagger schema generation
|
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: 4140f45 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 |
|
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. 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
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.
| customFields: unknown[]; | ||
| requirePasswordChange: boolean; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find and inspect the getUserInfo function
echo "=== Finding getUserInfo.ts ==="
GET_USER_INFO_FILE="$(fd '^getUserInfo\.ts$' apps/meteor --type f | head -n 1)"
echo "File: ${GET_USER_INFO_FILE}"
if [ -n "$GET_USER_INFO_FILE" ]; then
echo -e "\n=== Inspecting getUserInfo for customFields ==="
rg -n -C5 'customFields' "$GET_USER_INFO_FILE" | head -n 60
fi
# Find IUser interface definition
echo -e "\n=== Finding IUser interface ==="
rg -n 'interface IUser|type IUser' packages apps --type ts --type tsx | head -n 20
# Check customFields in IUser definitions
echo -e "\n=== Checking customFields in IUser ==="
rg -n -B2 -A2 'customFields' packages apps --type ts --type tsx | head -n 100Repository: RocketChat/Rocket.Chat
Length of output: 201
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look at the misc.ts file to see the IMeResponse and meResponseSchema
echo "=== Inspecting misc.ts file ==="
cat -n apps/meteor/app/api/server/v1/misc.ts | head -n 150Repository: RocketChat/Rocket.Chat
Length of output: 6610
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for actual /me endpoint implementation
echo "=== Finding /me endpoint implementation ==="
rg -n '\/me|getMeInfo' apps/meteor/app/api/server/v1 --type ts | head -n 30
# Check how customFields is passed or assembled
echo -e "\n=== Checking method calls or data assembly ==="
rg -n 'getUserInfo|getMeInfo' apps/meteor/app/api/server/v1/misc.ts -C3Repository: RocketChat/Rocket.Chat
Length of output: 207
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read getUserInfo.ts file
echo "=== getUserInfo.ts content ==="
cat -n apps/meteor/app/api/server/helpers/getUserInfo.tsRepository: RocketChat/Rocket.Chat
Length of output: 5362
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find IUser definition in core-typings
echo "=== Finding IUser interface ==="
fd -t f 'IUser|User' packages/core-typings/src --type typescript | head -n 20
# Look for customFields in User types
echo -e "\n=== Searching for customFields definition in core-typings ==="
rg -n 'customFields' packages/core-typings/src -A 2 -B 2 | head -n 100Repository: RocketChat/Rocket.Chat
Length of output: 292
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for the /me endpoint route definition properly (escape issue)
echo "=== Finding me endpoint route ==="
rg -n "get\('me'" apps/meteor/app/api/server/v1 --type ts
# Check how customFields is handled in user info context
echo -e "\n=== Checking customFields handling ==="
rg -n "customFields" apps/meteor/app/api/server --type ts | head -n 50Repository: RocketChat/Rocket.Chat
Length of output: 99
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find IUser definition
echo "=== Finding IUser definition ==="
find packages/core-typings/src -name '*.ts' -type f | xargs rg -l 'interface IUser|type IUser' | head -n 5
# Search for customFields in all User-related files
echo -e "\n=== Searching for customFields in core-typings ==="
rg -n 'customFields' packages/core-typings --type ts -B 2 -A 2 | head -n 80Repository: RocketChat/Rocket.Chat
Length of output: 3976
🏁 Script executed:
#!/bin/bash
set -euo pipefesh
# Check IUser in Users folder
echo "=== Finding User types in core-typings ==="
fd . packages/core-typings/src -name '*[Uu]ser*.ts' -type f | head -n 20Repository: RocketChat/Rocket.Chat
Length of output: 119
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Direct search for customFields type definition
echo "=== Checking actual customFields type in IUser ==="
rg -n 'customFields.*:' packages/core-typings -B 5 -A 2 --type ts | head -n 100Repository: RocketChat/Rocket.Chat
Length of output: 5301
customFields type mismatch will cause validation failures on valid /me responses.
customFields in IUser is defined as Record<string, any> in core-typings, but the schema models it as an array. The AJV validator will reject valid payloads where customFields is an object map, breaking endpoint behavior during migration.
Required fix
export interface IMeResponse {
@@
- customFields: unknown[];
+ customFields: Record<string, unknown>;
@@
export const meResponseSchema = {
@@
- customFields: { type: 'array', items: {} },
+ customFields: { type: 'object', additionalProperties: true },
@@
} as const;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| customFields: unknown[]; | |
| requirePasswordChange: boolean; | |
| customFields: Record<string, unknown>; | |
| requirePasswordChange: boolean; |
🤖 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 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.
Updated /api/v1/me endpoint: removed old @openapi block, added detected AJV schema and TypeScript interface, and cleaned up rest-typings imports.
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
packages/rest-typings/src/v1/me.ts
Outdated
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;
};
};
};2 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