fix(users.register): surface correct errorType from custom field validation

[rish106-hub]

When users.register validates custom fields, a validation failure throws Meteor.Error('error-user-registration-custom-field'). The catch block called API.v1.failure(e) passing the error object directly, which hit the isObject branch and lost the errorType. Fix: extract e.message and e.error before calling failure(), matching the pattern in APIClass.ts global catch. Test updated to assert the correct errorType directly. Closes #40765

Summary by CodeRabbit

• Bug Fixes
  • Enhanced error handling for user registration. When required custom fields are missing or invalid, the API now returns a more specific error type designed for custom field validation issues instead of a generic error message. This improvement helps applications better handle and communicate registration failures to users.

[dionisio-bot]

Looks like this PR is not ready to merge, because of the following issues:

• This PR is missing the 'stat: QA assured' label
• This PR is missing the required milestone or project

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: 67c7634

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@rocket.chat/meteor	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/rest-typings	Patch

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

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f47e3959-7b75-4080-a1c4-6829b1da1059

📥 Commits

Reviewing files that changed from the base of the PR and between 41943f1 and ebad5cd.

📒 Files selected for processing (3)

• .changeset/fix-custom-field-error-type.md
• apps/meteor/app/api/server/v1/users.ts
• apps/meteor/tests/end-to-end/api/users.ts

📜 Recent review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (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/tests/end-to-end/api/users.ts
• apps/meteor/app/api/server/v1/users.ts

🧠 Learnings (8)

📚 Learning: 2026-03-16T21:50:37.589Z

Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:37.589Z
Learning: For changes related to OpenAPI migrations in Rocket.Chat/OpenAPI, when removing endpoint types and validators from rocket.chat/rest-typings (e.g., UserRegisterParamsPOST, /v1/users.register) document this as a minor changeset (not breaking) per RocketChat/Rocket.Chat-Open-API#150 Rule 7. Note that the endpoint type is re-exposed via a module augmentation .d.ts in the consuming package (e.g., packages/web-ui-registration/src/users-register.d.ts). In reviews, ensure the changeset clearly states: this is a non-breaking change, the major version should not be bumped, and the changeset reflects a minor version bump. Do not treat this as a breaking change during OpenAPI migrations.

Applied to files:

• .changeset/fix-custom-field-error-type.md

📚 Learning: 2026-02-26T19:25:44.063Z

Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.

Applied to files:

• apps/meteor/tests/end-to-end/api/users.ts
• apps/meteor/app/api/server/v1/users.ts

📚 Learning: 2026-02-26T19:25:44.063Z

Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.

Applied to files:

• apps/meteor/tests/end-to-end/api/users.ts
• apps/meteor/app/api/server/v1/users.ts

📚 Learning: 2026-05-06T12:21:44.083Z

Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.

Applied to files:

• apps/meteor/tests/end-to-end/api/users.ts
• apps/meteor/app/api/server/v1/users.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/users.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/users.ts

📚 Learning: 2026-03-15T14:31:25.380Z

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:25.380Z
Learning: Do not flag this type/schema misalignment in the OpenAPI/migration review for apps/meteor/app/api/server/v1/users.ts. The UserCreateParamsPOST type intentionally uses non-optional fields: fields: string and settings?: IUserSettings without an AJV schema entry, carried over from the original rest-typings (PR `#39647`). Treat this as a known pre-existing divergence and document it as a separate follow-up fix; do not block or mark it as a review issue during the migration.

Applied to files:

• apps/meteor/app/api/server/v1/users.ts

📚 Learning: 2026-03-16T23:33:11.443Z

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:11.443Z
Learning: In rockets OpenAPI/AJV migration reviews for RocketChat/Rocket.Chat, when reviewing migrations that involve apps/meteor/app/api/server/v1/users.ts, do not require or flag a missing query AJV schema for the fields consumed by parseJsonQuery() (i.e., fields, sort, query) as part of this endpoint's migration PR. The addition of global query-param schemas for parseJsonQuery() usage is a cross-cutting concern and out of scope for individual endpoint migrations. Only flag violations related to the specific scope of the migration, not the absence of a query schema for parseJsonQuery() in this file.

Applied to files:

• apps/meteor/app/api/server/v1/users.ts

🔇 Additional comments (3)

apps/meteor/app/api/server/v1/users.ts (1)

902-904: LGTM!

apps/meteor/tests/end-to-end/api/users.ts (1)

1197-1197: LGTM!

.changeset/fix-custom-field-error-type.md (1)

1-5: LGTM!

---

Walkthrough

The PR fixes the error type returned by users.register when custom field validation fails. The implementation change updates error handling to extract and return message and error properties directly, while the test assertion now expects error-user-registration-custom-field instead of the generic error-invalid-body. A changeset entry documents this patch release.

Changes

Custom Field Validation Error Handling

Layer / File(s)	Summary
Custom field error handler and test apps/meteor/app/api/server/v1/users.ts, apps/meteor/tests/end-to-end/api/users.ts	The users.register validation catch block now passes e.message and e.error to API.v1.failure, enabling the correct error-user-registration-custom-field errorType to propagate. The corresponding test assertion is updated to expect this new errorType directly.
Release documentation .changeset/fix-custom-field-error-type.md	Changeset patch entry documents the fix that changes the error type returned for missing or invalid required custom fields in users.register.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested labels

type: bug

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing error type handling in users.register custom field validation, which is directly addressed by the code changes.
Linked Issues check	✅ Passed	The PR fully addresses issue #40765 by extracting e.message and e.error to preserve the correct errorType (error-user-registration-custom-field) and updating the test assertion accordingly.
Out of Scope Changes check	✅ Passed	All changes are scoped to fixing custom field error handling: the API handler logic, the changeset documentation, and the test assertion—no unrelated modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)

• ISSUE-40765: Request failed with status code 401

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}

[rish106-hub]

Hi @ggazzo @KevLehman — this is a small bug fix for users.register where the correct errorType (error-user-registration-custom-field) was being lost in the catch block when custom field validation fails. The fix is trivial (~3 min review per CodeRabbit), all automated checks are passing (cubic, CodeRabbit, CLA), and the branch is up to date with develop. Would really appreciate a review when you get a chance!