"Please enter different email error" displayed when navigate back to Work email modal

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.84-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/74548899/folder/57203762/41237586/1771052682?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocetest@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Other

Action Performed:

1. Login with new public domain user
2. Verify "What’s your work email?" modal is displayed
3. Enter any user with private domain (sdfasdfasdf@test.com for example)
4. Click Add work email button
5. Verify confirmation magic code modal is displayed
6. Navigate Back

Expected Result:

There should be no error message

Actual Result:

"Please enter a different email than the one you signed up with" error message is displayed
After several back and forward tries with different emails Add work email button become unresponsive

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7263050_1789721788145.Recording__1663.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7263050

Issue Owner

Current Issue Owner: @TaduJR

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c37b15005ebbd8605530f0c4106550f2599967cb401cefc3bb127cc97d77d212

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @amyevans (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Undetermined — no PR in the 9.4.84 checklist touches the affected code path (see Verification below). Keeping the existing DeployBlockerCash label until the trigger is confirmed.
Causing PR: None identified in the 9.4.84-1 StagingDeployCash checklist (Low confidence for every candidate I evaluated)
Related Issues: [$250] [Due for payment 2026-03-19] Onboarding work email: re-add public domain validation and prevent same-email submission — the issue that introduced the validation rule producing this exact copy

Recommendation: NEEDS INVESTIGATION

Every file in this flow (the onboarding work-email pages, the whole src/components/Form library, Session/Welcome actions, and the en strings) is byte-identical between production and staging, so there is no App PR in this release to revert. @amyevans — could we get the tester to re-confirm production and grab a requestID for the AddWorkEmail call, so we can tell whether the backend response is what changed?

Labels: No changes. DeployBlockerCash kept (no causing App PR ruled in or out, and the issue is reported as not reproducible on production).

📋 Detailed Analysis

Evidence

The reported copy has exactly one source in the codebase — the validate() callback on the onboarding work-email form:

App/src/pages/OnboardingWorkEmail/BaseOnboardingWorkEmail.tsx

Lines 157 to 179 in b1f7a98

	const validate = (values: FormOnyxValues<typeof ONYXKEYS.FORMS.ONBOARDING_WORK_EMAIL_FORM>) => {
	if (!shouldValidateOnChange) {
	setShouldValidateOnChange(true);
	}
	const userEmail = values[INPUT_IDS.ONBOARDING_WORK_EMAIL].trim();
	const errors = {};
	const emailParts = userEmail.split('@');
	const domain = emailParts.at(1) ?? '';
	if (session?.email && userEmail.toLowerCase() === session.email.toLowerCase() && !isOffline) {
	addErrorMessage(errors, INPUT_IDS.ONBOARDING_WORK_EMAIL, translate('onboarding.workEmailValidationError.sameAsSignupEmail'));
	} else if ((!Str.isValidEmail(userEmail) || PUBLIC_DOMAINS_SET.has(domain.toLowerCase())) && !isOffline) {
	Log.hmmm('User is trying to add an invalid work email', {userEmail, domain});
	addErrorMessage(errors, INPUT_IDS.ONBOARDING_WORK_EMAIL, translate('onboarding.workEmailValidationError.publicEmail'));
	}
	if (isOffline ?? false) {
	addErrorMessage(errors, INPUT_IDS.ONBOARDING_WORK_EMAIL, translate('onboarding.workEmailValidationError.offline'));
	}
	return errors;
	};

if (session?.email && userEmail.toLowerCase() === session.email.toLowerCase() && !isOffline) {
    addErrorMessage(errors, INPUT_IDS.ONBOARDING_WORK_EMAIL, translate('onboarding.workEmailValidationError.sameAsSignupEmail'));
}

It is a purely local field error (it is never written to Onyx and the backend cannot set it), so for the tester to see it after typing sdfasdfasdf@test.com, session.email must have become the submitted work email by the time the user navigates back from the security-code screen. That points at the AddWorkEmail round trip mutating session.email rather than at the validation itself.

That guard was added in Re-add public domain validation and prevent same-email submission on onboarding work email (merged 2026-03-11) and has been on production for six months, so it is not new in this release.

The secondary symptom ("Add work email button becomes unresponsive") has a separate, plausible frontend cause: FormProvider returns early from submit whenever the Onyx form's isLoading is set, and AddWorkEmail sets isLoading: true optimistically with nothing resetting it if the user leaves the screen before the request settles.

• FormProvider submit gate:

  App/src/components/Form/FormProvider.tsx

  Lines 300 to 309 in b1f7a98

  	const isExternalLoading = !!formState?.isLoading || isOnyxLoading;
  	const {isLoading: isPressLoading, startWithLoading} = usePressLoading({isLoading: isExternalLoading});
  	const isLoading = shouldShowLoadingImmediatelyOnPress ? isPressLoading : isExternalLoading;
  	const submit = useDebounceNonReactive(
  	useCallback(() => {
  	// Return early if the form is already submitting to avoid duplicate submission
  	if (isLoading) {
  	return;
  	}

• AddWorkEmail optimistic isLoading:

  App/src/libs/actions/Session/index.ts

  Lines 1659 to 1686 in b1f7a98

  	function AddWorkEmail(workEmail: string, formID: AddWorkEmailFormID = ONYXKEYS.FORMS.ONBOARDING_WORK_EMAIL_FORM) {
  	const isOnboardingFlow = formID === ONYXKEYS.FORMS.ONBOARDING_WORK_EMAIL_FORM;
  	const optimisticData: Array<OnyxUpdate<AddWorkEmailFormID | typeof ONYXKEYS.ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY>> = isOnboardingFlow
  	? [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: ONYXKEYS.FORMS.ONBOARDING_WORK_EMAIL_FORM,
  	value: {
  	onboardingWorkEmail: workEmail,
  	isLoading: true,
  	},
  	},
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: ONYXKEYS.ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY,
  	value: null,
  	},
  	]
  	: [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: ONYXKEYS.FORMS.ADD_WORK_EMAIL_FORM,
  	value: {
  	isLoading: true,
  	errorFields: null,
  	},
  	},

• Back-button handler that returns to this screen:

  App/src/libs/actions/Welcome/index.ts

  Lines 94 to 102 in b1f7a98

  	function updateOnboardingValuesAndNavigation(onboardingValues: Onboarding | undefined) {
  	Onyx.set(ONYXKEYS.NVP_ONBOARDING, {...onboardingValues, shouldValidate: undefined});
  	// We need to have the Onyx values updated before navigating back
  	// Because we navigate based no useEffect logic and we need to clear `shouldValidate` value before going back
  	Navigation.setNavigationActionToMicrotaskQueue(() => {
  	Navigation.goBack(ROUTES.ONBOARDING_WORK_EMAIL.getRoute());
  	});
  	}

Verification

I compared production (9.4.81-1) against staging (9.4.84-1) across the full 597-file diff, and separately checked blob SHAs via the GitHub contents/commits API (which is authoritative and not affected by a shallow clone):

Path	production	staging
src/pages/OnboardingWorkEmail/ (all 4 files)	identical	identical
src/pages/OnboardingWorkEmailValidation/BaseOnboardingWorkEmailValidation.tsx	9842a669d (2026-08-08)	9842a669d
src/components/Form/ (all 8 files)	identical	identical
src/libs/actions/Session/index.ts	a16bad68f (2026-09-11)	a16bad68f
src/libs/actions/Welcome/index.ts	752dc5672 (2026-07-06)	752dc5672
src/languages/* onboarding.workEmailValidationError.*	unchanged	unchanged

Nothing in the import graph of BaseOnboardingWorkEmail changed either — the only onboarding-adjacent files in the release diff are src/components/OnboardingHelpDropdownButton.tsx and src/hooks/useCompleteOnboarding.ts, neither of which is on this code path.

Candidates I ruled out after reading their diffs (all touch shared infrastructure but none touch session email, form validation, or onboarding navigation):

• Recover the Pusher apply chain after a rejection, behind a watermark continuity guard — OnyxUpdates.ts / User.ts; changes update-chain recovery only
• Fix time display format by using localized format — LocaleContextProvider / IntlStore; date-format only, translate identity unchanged
• Route personal details reads through PersonalDetailsStore and hooks — personal details, not session
• Fix infinite loading and missing error on the workspace add work email pages — the only recent AddWorkEmail change, but it merged 2026-09-11 and is already on production

Root Cause

Not established. Two hypotheses, in order of likelihood:

1. Backend/data trigger. AddWorkEmail's response (or a Pusher update following it) now leaves session.email set to the submitted work email before the merge is validated. The frontend guard then fires correctly-but-uselessly on the way back. If confirmed, the frontend should still be hardened: compare against the signup login captured at sign-in rather than live session.email, and skip the check for an address that is merely pending validation.
2. Pre-existing frontend bug that Applause reached for the first time via exploratory testing (bug source is listed as Exploratory), in which case "not reproducible in production" is unreliable — onboarding only runs once per account, so a production re-test needs a brand new public-domain signup.

The stuck submit button is independently reproducible from code reading and should be fixed regardless, by clearing ONBOARDING_WORK_EMAIL_FORM.isLoading when the work-email screen regains focus.

[nlemma]

This bug shows up on every PR, so it’s hard to pinpoint the PR that caused it.

[MelvinBot]

🤖 Addendum to the investigation above — no App PR in this release can be reverted for this.

Bottom line: every file in this flow (the onboarding work-email pages, the whole src/components/Form library, and the Session/Welcome actions) is byte-identical between production (9.4.81-1) and staging (9.4.84-1), so there is no causing PR in the 9.4.84 checklist. The full evidence — blob-SHA comparison per file, plus the candidate PRs I read and ruled out — is in the detailed comment.

What I'd do next:

1. Re-test on production with a brand new public-domain signup. Onboarding runs once per account, so the "not reproducible in production" signal is weak — and staging App points at the production API, so a pure backend change should break both.
2. Grab a requestID for the AddWorkEmail call. The error copy is a purely local field error with one producer that compares the typed address to live session.email — so it can only fire on a different address if AddWorkEmail has already mutated session.email to the submitted work email.

One fix worth making regardless of the trigger: the stuck "Add work email" button is independently explainable from code. AddWorkEmail sets isLoading: true optimistically (src/libs/actions/Session/index.ts:1659-1686) and FormProvider returns early from submit while it's set — with nothing clearing it if the user navigates back before the request settles. Clearing ONBOARDING_WORK_EMAIL_FORM.isLoading when that screen regains focus fixes the unresponsive button.

I also tried to reproduce this on web to settle hypothesis 1, but the test session was unusable (the app client had gone blank before handoff), so that attempt produced no repro data either way.

DeployBlockerCash left in place — I can't rule a PR in or out, so demoting it isn't mine to call. amyevans, over to you on the production re-test.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

---

view run · no recording available

[amyevans]

I've not been able to reproduce 🤔 . I've tried a couple times, here's one for instance:

Screen.Recording.2026-09-18.at.9.37.50.AM.mov

I'm investigating backend code/logs though to see if anything comes up

[amyevans]

Alright turns out it's slightly different steps needed to reproduce:

1. Sign up fresh with a gmail address. Do not validate it.
2. Enter a work email nobody has ever used, on an uncontrolled domain.
3. Confirm you landed on the private-domain screen (the magic code goes to the work email you just typed, not your gmail)
4. Press back.

With that I'm able to reproduce on production:

Screen.Recording.2026-09-18.at.9.58.35.AM.mov

So not a deploy blocker