chore: Add OpenAPI support for teams discovery endpoints#39945
Open
vivekyarra wants to merge 1 commit intoRocketChat:developfrom
Open
chore: Add OpenAPI support for teams discovery endpoints#39945vivekyarra wants to merge 1 commit intoRocketChat:developfrom
vivekyarra wants to merge 1 commit intoRocketChat:developfrom
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: 148aecf The changes in this PR will be included in the next version bump. This PR includes changesets to release 41 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
WalkthroughAdded OpenAPI support for team discovery endpoints by introducing AJV-based query validation and explicit response schemas for six team read operations, replacing inline validation assertions with schema-driven route definitions while preserving underlying business logic. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 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 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/teams.ts`:
- Around line 97-110: The TeamsMembersQuerySchema's status property only
declares type: 'array' so a single string query like ?status=online fails under
current ajvQuery coercion; update the TeamsMembersQuerySchema to accept both a
string and an array (e.g., set status type to ['array','string'] with items: {
type: 'string' }) and then normalize/coerce the value in the request handler
(e.g., if typeof status === 'string' convert to [status]) so both repeated
params and single values validate and work; reference TeamsMembersQuerySchema
and the status property for the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f1edb0c9-eeb4-437e-8f8f-d0940cd364ff
📒 Files selected for processing (2)
.changeset/teams-discovery-openapi.mdapps/meteor/app/api/server/v1/teams.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/teams.ts
🧠 Learnings (17)
📓 Common learnings
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: apps/meteor/app/api/server/v1/users.ts:862-869
Timestamp: 2026-03-16T23:33:15.721Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs (e.g., PR `#39676` for users.register in apps/meteor/app/api/server/v1/users.ts), calls to `this.parseJsonQuery()` inside migrated handlers are intentionally preserved without adding a corresponding `query` AJV schema to the route options. Adding query-param schemas for the `fields`/`sort`/`query` parameters consumed by `parseJsonQuery()` is a separate cross-cutting concern shared by many endpoints (e.g., users.create, users.update, users.list) and is explicitly out of scope for individual endpoint migration PRs. Do not flag the absence of a `query` schema for `parseJsonQuery()` usage as a violation of OpenAPI/AJV contract during migration reviews.
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: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39414
File: apps/meteor/app/api/server/v1/rooms.ts:1241-1297
Timestamp: 2026-03-10T08:13:52.153Z
Learning: In the RocketChat/Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1/rooms.ts, the pattern `ajv.compile<void>({...})` is intentionally used for the 200 response schema even when the endpoint returns `{ success: true }`. This is an established convention across all migrated endpoints (rooms.leave, rooms.favorite, rooms.delete, rooms.muteUser, rooms.unmuteUser). Do not flag this as a type mismatch during reviews of these migration PRs.
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/api/server/v1/stats.ts:98-117
Timestamp: 2026-03-20T13:52:29.575Z
Learning: In `apps/meteor/app/api/server/v1/stats.ts`, the `statistics.telemetry` POST endpoint intentionally has no `body` AJV schema in its route options. The proper request body shape (a `params` array of telemetry event objects) has not been formally defined yet, so body validation is deferred to a follow-up. Do not flag the missing body schema for this endpoint during OpenAPI migration reviews.
📚 Learning: 2026-02-24T19:09:09.561Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
Applied to files:
.changeset/teams-discovery-openapi.md
📚 Learning: 2026-02-24T19:05:56.710Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 0
File: :0-0
Timestamp: 2026-02-24T19:05:56.710Z
Learning: Rocket.Chat repo context: When a workspace manifest on develop already pins a dependency version (e.g., packages/web-ui-registration → "rocket.chat/ui-contexts": "27.0.1"), a lockfile change in a feature PR that upgrades only that dependency’s resolution is considered a manifest-driven sync and can be kept, preferably as a small "chore: sync yarn.lock with manifests" commit.
Applied to files:
.changeset/teams-discovery-openapi.md
📚 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/teams-discovery-openapi.md
📚 Learning: 2026-03-14T14:58:58.834Z
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Applied to files:
.changeset/teams-discovery-openapi.mdapps/meteor/app/api/server/v1/teams.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:
.changeset/teams-discovery-openapi.mdapps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-16T23:33:15.721Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: apps/meteor/app/api/server/v1/users.ts:862-869
Timestamp: 2026-03-16T23:33:15.721Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs (e.g., PR `#39676` for users.register in apps/meteor/app/api/server/v1/users.ts), calls to `this.parseJsonQuery()` inside migrated handlers are intentionally preserved without adding a corresponding `query` AJV schema to the route options. Adding query-param schemas for the `fields`/`sort`/`query` parameters consumed by `parseJsonQuery()` is a separate cross-cutting concern shared by many endpoints (e.g., users.create, users.update, users.list) and is explicitly out of scope for individual endpoint migration PRs. Do not flag the absence of a `query` schema for `parseJsonQuery()` usage as a violation of OpenAPI/AJV contract during migration reviews.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-20T13:52:29.575Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/api/server/v1/stats.ts:98-117
Timestamp: 2026-03-20T13:52:29.575Z
Learning: In `apps/meteor/app/api/server/v1/stats.ts`, the `statistics.telemetry` POST endpoint intentionally has no `body` AJV schema in its route options. The proper request body shape (a `params` array of telemetry event objects) has not been formally defined yet, so body validation is deferred to a follow-up. Do not flag the missing body schema for this endpoint during OpenAPI migration reviews.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-15T14:31:28.969Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-10T08:13:52.153Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39414
File: apps/meteor/app/api/server/v1/rooms.ts:1241-1297
Timestamp: 2026-03-10T08:13:52.153Z
Learning: In the RocketChat/Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1/rooms.ts, the pattern `ajv.compile<void>({...})` is intentionally used for the 200 response schema even when the endpoint returns `{ success: true }`. This is an established convention across all migrated endpoints (rooms.leave, rooms.favorite, rooms.delete, rooms.muteUser, rooms.unmuteUser). Do not flag this as a type mismatch during reviews of these migration PRs.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-16T21:50:42.118Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 Learning: 2026-03-12T10:26:26.697Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39340
File: apps/meteor/app/api/server/v1/im.ts:1349-1398
Timestamp: 2026-03-12T10:26:26.697Z
Learning: In `apps/meteor/app/api/server/v1/im.ts` (PR `#39340`), the `DmEndpoints` type intentionally includes temporary stub entries for `/v1/im.kick`, `/v1/dm.kick`, `/v1/im.leave`, and `/v1/dm.leave` (using `DmKickProps` and `DmLeaveProps`) even though no route handlers exist for them yet. These stubs were added to preserve type compatibility after removing the original `DmLeaveProps` and related files. They are planned for cleanup in a follow-up PR. Do not flag these as missing implementations when reviewing this file until the follow-up is merged.
Applied to files:
apps/meteor/app/api/server/v1/teams.ts
📚 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/teams.ts
📚 Learning: 2025-11-27T17:56:26.050Z
Learnt from: MartinSchoeler
Repo: RocketChat/Rocket.Chat PR: 37557
File: apps/meteor/client/views/admin/ABAC/AdminABACRooms.tsx:115-116
Timestamp: 2025-11-27T17:56:26.050Z
Learning: In Rocket.Chat, the GET /v1/abac/rooms endpoint (implemented in ee/packages/abac/src/index.ts) only returns rooms where abacAttributes exists and is not an empty array (query: { abacAttributes: { $exists: true, $ne: [] } }). Therefore, in components consuming this endpoint (like AdminABACRooms.tsx), room.abacAttributes is guaranteed to be defined for all returned rooms, and optional chaining before calling array methods like .join() is sufficient without additional null coalescing.
Applied to files:
apps/meteor/app/api/server/v1/teams.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/teams.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/teams.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/teams.ts
🔇 Additional comments (10)
.changeset/teams-discovery-openapi.md (1)
1-5: LGTM!The changeset correctly declares a
patchrelease for the OpenAPI migration. This is appropriate since the PR adds schema-based validation and documentation without changing business logic or removing types from rest-typings.apps/meteor/app/api/server/v1/teams.ts (9)
6-21: LGTM!Imports correctly bring in
ajvQueryfor query validation (with type coercion for HTTP query strings) andajvfor response schemas. Error response validators align with the HTTP status codes used in route definitions.
34-63: LGTM!Type definitions accurately model the query parameters. The optional TypeScript properties combined with
oneOfschema constraints correctly enforce that at least one identifier is provided at runtime.
127-275: LGTM!Response schemas correctly define the expected payloads. Using
$refforITeamandIRoommaintains consistency with centralized component schemas. TheteamsMembersResponseSchemaproperly handles nullableroleswithoneOf: [array, null].
277-301: LGTM!Clean migration to the new
API.v1.getpattern with appropriate query validation and response schemas. Handler logic is preserved.
303-328: LGTM!Correctly includes
403response schema for the permission-required endpoint. Migration preserves theview-all-teamspermission check.
652-678: LGTM!Migration correctly uses the existing
isTeamsListChildrenPropsvalidator from rest-typings. The404response schema properly documents theAPI.v1.notFound()return path.
680-718: LGTM!Migration correctly includes
403response for the permission-gated flow. Handler logic is preserved with proper status/username/name filter extraction.
850-883: LGTM!Migration correctly documents error responses. Note: Team/Room not found returns
400viaAPI.v1.failure()rather than404— this preserves existing behavior and the schema accurately reflects it.
912-930: LGTM!Clean migration with strict schema validation (
additionalProperties: false,minLength: 1). The minimal response schema coverage (200, 400, 401) matches the simple handler logic.
Comment on lines
+97
to
+110
| const TeamsMembersQuerySchema = { | ||
| type: 'object', | ||
| properties: { | ||
| teamId: { type: 'string', nullable: true }, | ||
| teamName: { type: 'string', nullable: true }, | ||
| status: { type: 'array', items: { type: 'string' }, nullable: true }, | ||
| username: { type: 'string', nullable: true }, | ||
| name: { type: 'string', nullable: true }, | ||
| count: { type: 'number', nullable: true }, | ||
| offset: { type: 'number', nullable: true }, | ||
| }, | ||
| oneOf: [{ required: ['teamId'] }, { required: ['teamName'] }], | ||
| additionalProperties: true, | ||
| } as const; |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for how status param is used in client calls to teams.members
rg -n -C3 'teams\.members' --type=ts --type=tsx -g '!*.test.*' -g '!*spec*' | head -50Repository: RocketChat/Rocket.Chat
Length of output: 93
🌐 Web query:
Does AJV coerceTypes: true automatically coerce single string to array?
💡 Result:
No, AJV with coerceTypes: true does not automatically coerce a single string to an array. With coerceTypes: true, AJV performs coercion between scalar types (string, number, boolean, null) according to specific rules, such as string to number if the string is numeric, or string "true"/"false" to boolean. However, coercion from a string (or other scalar) to an array requires coerceTypes: "array". The official documentation explicitly states that array coercions need {coerceTypes: "array"}, and shows examples like "foo" → ["foo"] only in that mode.
Citations:
- 1: https://ajv.js.org/coercion.html
- 2: https://ajv.js.org/guide/modifying-data.html
- 3: https://ajv.js.org/options.html
🏁 Script executed:
# First, let's examine the teams.ts file to understand ajvQuery configuration and endpoint implementation
cat -n apps/meteor/app/api/server/v1/teams.ts | head -150Repository: RocketChat/Rocket.Chat
Length of output: 5402
🏁 Script executed:
# Search for ajvQuery configuration in the teams.ts file
rg -n "ajvQuery\|coerceTypes" apps/meteor/app/api/server/v1/teams.tsRepository: RocketChat/Rocket.Chat
Length of output: 48
🏁 Script executed:
# Find the teams.members endpoint implementation
rg -n -A 20 "teams\.members|TeamsMembersQuerySchema" apps/meteor/app/api/server/v1/teams.tsRepository: RocketChat/Rocket.Chat
Length of output: 2292
🏁 Script executed:
# Check for similar array-type query parameters in other v1 endpoints
rg -n "type.*array.*items" apps/meteor/app/api/server/v1/ --type=ts | head -20Repository: RocketChat/Rocket.Chat
Length of output: 2279
🏁 Script executed:
# Find where ajvQuery is initialized and what coerceTypes setting is used
rg -n "ajvQuery.*=" --type=ts -A 3 | grep -A 3 "coerceTypes"Repository: RocketChat/Rocket.Chat
Length of output: 251
🏁 Script executed:
# Find where ajvQuery is imported/exported from rest-typings
rg -n "export.*ajvQuery\|const ajvQuery" --type=tsRepository: RocketChat/Rocket.Chat
Length of output: 48
🏁 Script executed:
# Check the actual endpoint usage - does it expect array or handle single value?
rg -n -B 5 -A 10 "status.*this.queryParams" apps/meteor/app/api/server/v1/teams.tsRepository: RocketChat/Rocket.Chat
Length of output: 651
🏁 Script executed:
# Search for how status is actually used in the endpoint logic
rg -n -A 20 "const.*status.*=.*queryParams" apps/meteor/app/api/server/v1/teams.tsRepository: RocketChat/Rocket.Chat
Length of output: 855
🏁 Script executed:
# Check if there are other array query parameters in teams.ts or similar endpoints
rg -B 2 "type.*array.*items.*type.*string.*nullable" apps/meteor/app/api/server/v1/teams.tsRepository: RocketChat/Rocket.Chat
Length of output: 231
🏁 Script executed:
# Look for any documentation or handling of array query params in the codebase
rg -n "coerceTypes.*array" --type=tsRepository: RocketChat/Rocket.Chat
Length of output: 48
🏁 Script executed:
# Check if status parameter is tested anywhere to see expected behavior
rg -n "teams\.members.*status" --type=ts -g '!*.test.*' -g '!*spec*' | head -20Repository: RocketChat/Rocket.Chat
Length of output: 48
The status array query parameter lacks proper AJV coercion configuration.
With ajvQuery configured as coerceTypes: true, a single string value (e.g., ?status=online) will fail validation — array coercion requires coerceTypes: 'array'. Repeated parameters (?status=online&status=away) work because HTTP frameworks parse them as arrays natively, but the schema should clarify the intended usage or the AJV config should be adjusted.
Either:
- Update the schema to accept
type: 'string'and coerce within the handler, or - Configure
ajvQueryto usecoerceTypes: 'array', or - Document that
statusonly accepts repeated query parameters.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/meteor/app/api/server/v1/teams.ts` around lines 97 - 110, The
TeamsMembersQuerySchema's status property only declares type: 'array' so a
single string query like ?status=online fails under current ajvQuery coercion;
update the TeamsMembersQuerySchema to accept both a string and an array (e.g.,
set status type to ['array','string'] with items: { type: 'string' }) and then
normalize/coerce the value in the request handler (e.g., if typeof status ===
'string' convert to [status]) so both repeated params and single values validate
and work; reference TeamsMembersQuerySchema and the status property for the
change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed changes
Migrates 6 teams discovery/listing endpoints from the deprecated
API.v1.addRoutepattern to the new
API.v1.getpattern with full OpenAPI support.Endpoints migrated:
teams.listteams.listAllteams.listChildrenteams.membersteams.infoteams.autocompleteChanges per endpoint:
Issue(s)
Relates to #34983
Steps to test or reproduce
GET /api/v1/teams.list— returns paginated team listGET /api/v1/teams.listAll— returns all teams (admin only)GET /api/v1/teams.listChildren?teamId=xxx— returns team roomsGET /api/v1/teams.members?teamId=xxx— returns team membersGET /api/v1/teams.info?teamId=xxx— returns team infoGET /api/v1/teams.autocomplete?name=xxx— returns autocomplete resultsFurther comments
GSoC 2026 contributor applying for the OpenClaw Integration project.
Second qualifying PR following the same migration pattern as #39225, #39227, and #39932.
Summary by CodeRabbit
Release Notes