fix: validate username availability against API in Setup Wizard admin step

[amitkumarashutosh]

Proposed changes

Replace the missing username availability API check in AdminInfoStep with a proper async validation using the checkUsernameAvailability endpoint exposed through SetupWizardContext.

The following function is now async and calls the API:

validateUsername

The following method is added to SetupWizarContextValue type and default context value:

checkUsernameAvailability

The following callback is implemented and exposed in context:

checkUsernameAvailability via useEndpoint('GET', '/v1/users.checkUsernameAvailability')

Before

// TODO: check if username exists
const validateUsername = (username: string): boolean | string => {
	if (!usernameRegExp.test(username) || hasBlockedName(username)) {
		return t('Invalid_username');
	}
	return true;
};

After

const validateUsername = async (username: string): Promise<boolean | string> => {
	if (!usernameRegExp.test(username) || hasBlockedName(username)) {
		return t('Invalid_username');
	}
	const isAvailable = await checkUsernameAvailability(username);
	if (!isAvailable) {
		return t('Username_already_exist');
	}
	return true;
};

Issue(s)

Closes #38990

Steps to reproduce

See packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx
See packages/ui-client/src/views/setupWizardcontexts/SetupWizardContext.ts
See packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx

Testing

• No runtime behavior changes beyond the added API call
• Verify that entering an already taken username during setup wizard shows Username_already_exist error
• Verify that entering a valid, available username proceeds normally

Summary by CodeRabbit

• New Features
  • Username availability is now validated in real-time during admin user setup, preventing duplicate usernames from being registered.
  • Asynchronous validation ensures accurate server-side checks before account creation.

COMM-144

[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 targeting the wrong base branch. It should target 8.4.0, but it targets 8.3.0

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[changeset-bot]

⚠️ No Changeset found

Latest commit: e2373df

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

This PR adds username availability validation to the setup wizard's admin registration step by introducing a new context-exposed API function. The function queries the GET /v1/users.checkUsernameAvailability endpoint and integrates asynchronous availability checking into the username validation flow.

Changes

Cohort / File(s)	Summary
Context Type Definition packages/ui-client/src/views/setupWizard/contexts/SetupWizardContext.tsx	Added checkUsernameAvailability function signature to SetupWizardContextValue type with default async implementation returning true.
Provider Implementation packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx	Introduced endpoint hook for username availability check and exposed the function through context value, updating dependency arrays for memoization.
Admin Registration Step packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx	Integrated availability check into username validation, converting validation to async and returning Username_already_exist error when username is unavailable.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A username check hops into place,
No duplicates in this setup race!
Async validation, smooth and clean,
The finest admin screen we've seen! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding API-backed username availability validation in the Setup Wizard admin step.
Linked Issues check	✅ Passed	The PR successfully implements all requirements from issue #38990: adds checkUsernameAvailability to context and provider, implements async username validation via API endpoint, and returns appropriate error when username is unavailable.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing the username availability check requirement; no extraneous modifications were introduced.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ 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.

❤️ 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

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx (1)

55-82: ⚠️ Potential issue | 🔴 Critical

Endpoint is unreachable during unauthenticated setup—catches auth failures as "username unavailable".

The endpoint requires authRequired: true and calls checkUsernameAvailabilityWithValidation(this.userId, username), which throws error-invalid-user when userId is missing. This function is called during form validation (in validateUsername()) before registerAdminUser() logs in the user. The catch block returns false, which surfaces as 'Username_already_exist', blocking setup progression. Either make the endpoint unauthenticated for setup context, or defer the check until after registration/login, or throw/return a union to distinguish auth failures from unavailable usernames.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx`
around lines 55 - 82, The current checkUsernameAvailability callback swallows
auth failures from checkUsernameAvailabilityEndpoint and returns false so
validateUsername() reports 'Username_already_exist' during unauthenticated
setup; update the logic in checkUsernameAvailability (or the endpoint config) so
auth-missing errors are distinguished: either make the endpoint unauthenticated
(authRequired: false) used for setup, or change checkUsernameAvailability to
inspect the thrown error (e.g., error-invalid-user / missing userId) and either
rethrow or return a distinct result (or true) so validateUsername() doesn't
treat auth failure as "username unavailable"; reference functions:
checkUsernameAvailabilityEndpoint, checkUsernameAvailability,
validateUsername(), registerAdminUser().

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx`:
- Around line 55-82: The current checkUsernameAvailability callback swallows
auth failures from checkUsernameAvailabilityEndpoint and returns false so
validateUsername() reports 'Username_already_exist' during unauthenticated
setup; update the logic in checkUsernameAvailability (or the endpoint config) so
auth-missing errors are distinguished: either make the endpoint unauthenticated
(authRequired: false) used for setup, or change checkUsernameAvailability to
inspect the thrown error (e.g., error-invalid-user / missing userId) and either
rethrow or return a distinct result (or true) so validateUsername() doesn't
treat auth failure as "username unavailable"; reference functions:
checkUsernameAvailabilityEndpoint, checkUsernameAvailability,
validateUsername(), registerAdminUser().

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 55bf071 and f689e72.

📒 Files selected for processing (3)

• packages/ui-client/src/views/setupWizard/contexts/SetupWizardContext.tsx
• packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx
• packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx

📜 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). (3)

• GitHub Check: 📦 Build Packages
• GitHub Check: cubic · AI code reviewer
• GitHub Check: CodeQL-Build

🧰 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:

• packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx
• packages/ui-client/src/views/setupWizard/contexts/SetupWizardContext.tsx
• packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx

🧬 Code graph analysis (2)

packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx (1)

packages/ui-contexts/src/index.ts (1)

• useEndpoint (34-34)

packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx (1)

packages/ui-client/src/views/setupWizard/contexts/SetupWizardContext.tsx (1)

• useSetupWizardContext (74-74)

🔇 Additional comments (5)

packages/ui-client/src/views/setupWizard/contexts/SetupWizardContext.tsx (2)

19-38: Context type extension is clear and properly typed.

---

40-71: Default stub for checkUsernameAvailability is fine for non-provider usage.

packages/ui-client/src/views/setupWizard/steps/AdminInfoStep.tsx (2)

20-20: Context consumption update looks good.

---

42-52: No action required.
The async validateUsername validator is correctly implemented and used. The code compiles without TypeScript errors, confirming that AdminInfoPage from @rocket.chat/onboarding-ui accepts async validators with the Promise<boolean | string> signature.

packages/ui-client/src/views/setupWizard/providers/SetupWizardProvider.tsx (1)

204-242: Context value wiring and memo deps look consistent.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.62%. Comparing base (55bf071) to head (e2373df).
⚠️ Report is 124 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #38991      +/-   ##
===========================================
- Coverage    70.64%   70.62%   -0.03%     
===========================================
  Files         3189     3189              
  Lines       112716   112716              
  Branches     20413    20427      +14     
===========================================
- Hits         79632    79606      -26     
- Misses       31040    31058      +18     
- Partials      2044     2052       +8     

Flag	Coverage Δ
e2e	60.32% <ø> (-0.09%)	⬇️
e2e-api	47.79% <ø> (-0.15%)	⬇️
unit	71.20% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.