[$250] Wrong error message after adding work email account with 2FA enabled

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88287
Email or phone of affected tester (no customers): applausetester+vq+1104@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: User Settings

Action Performed:

Preconditions: An Expensifail account with 2FA enabled.

1. Scenario: 2FA error is displayed when user attempts to enter a work email already associated with an account with 2FA enabled

2. Navigate to new expensify

3. Enter a new email id, and click on continue button.

4. Click on join button

5. Wait for new onboarding flow popup.

6. On 'what's your work email' popup, enter a work email already associated with an account with 2FA enabled.

7. Click on add work email button.

Expected Result:

Error should be displayed with the message ' is a login for an Expensify account with Two-Factor Authentication (2FA) enabled.'
"This login is an existing account with Two-Factor Authentication (2FA) enabled."

Actual Result:

Couldn’t add work email
We couldn’t add applausetester+vq+1104@applause.expensifail.com. Please try again later in Settings or chat with Concierge for guidance.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7161770_1779597097686.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7161770

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058788479476404717
• Upwork Job ID: 2058788479476404717
• Last Price Increase: 2026-05-25

[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/d1aaaadf11faf32e436f4d0647f6c98ce31852b7a3b956e48e5120922efb341c

[MelvinBot]

Issue Analysis

Duplicate of #86194 — that issue describes the same root cause, is labeled Reviewing, and is assigned to grgia with active proposals being evaluated.

Root Cause: In Session/index.ts:1514, the AddWorkEmail handler checks response?.message?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR) to detect the 2FA error. If the backend message doesn't contain the exact substring "is a login for an Expensify account with Two-Factor Authentication (2FA) enabled", the check fails and execution falls through to line 1523, which sets only isMergingAccountBlocked: true without setting the error translation key.

This causes OnboardingMergingAccountBlockedView.tsx:33 to use the generic fallback: "We couldn't add {email}. Please try again later in Settings or chat with Concierge for guidance."

Recommended Fix: Since this is already tracked in #86194, this issue should be closed as a duplicate.

---

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

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user in the onboarding "what's your work email" step enters a work email that is already associated with an Expensify account that has 2FA enabled, the app shows the generic blocking screen ("Couldn't add work email… Please try again later in Settings or chat with Concierge for guidance.") instead of the dedicated 2FA error message "This login is an existing account with Two-Factor Authentication (2FA) enabled." Reproduces on iOS, Android, and Web.

What is the root cause of that problem?

In src/libs/actions/Session/index.ts at the AddWorkEmail response handler (around line 1514), the 2FA branch only inspects response?.message?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR). For this server error the 2FA error string is returned on response.title (and/or response.htmlMessage), not on response.message — the same reason the adjacent WORK_ACCOUNT_CLOSED_ERROR branch at line 1519 checks both response?.message and response?.title. Because neither the 2FA nor the closed-account predicate matches, control falls through to the final Onyx.merge(ONYXKEYS.NVP_ONBOARDING, {isMergingAccountBlocked: true}) line, which is what renders the generic "Couldn't add work email" block screen the user sees.

What changes do you think we should make in order to solve the problem?

1. src/libs/actions/Session/index.ts ~line 1514 — broaden the 2FA detection to mirror the closed-account check by also inspecting response?.title and response?.htmlMessage, e.g. if ([response?.message, response?.title, response?.htmlMessage].some((field) => field?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR))). This sets ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY to 'onboarding.workEmail2FAError' so the inline error renders instead of the block screen.
2. Confirm by logging/inspecting the live EXP_ERROR response shape for this scenario (Applause repro: applausetester+vq+1104@applause.expensifail.com) so the precise field is matched — adjust the union above accordingly.
3. No platform-specific (iOS/Android/web) twin files exist for AddWorkEmail; the single fix covers all three reported platforms because BaseOnboardingWorkEmail.tsx is shared and shouldRenderOfflineFeedback already whitelists 'onboarding.workEmail2FAError' (line 122) to suppress the offline-feedback wrapper.
4. No translation changes needed — en.ts line 3092 and the 9 sibling language files already include onboarding.workEmail2FAError from PR add descriptive error message for work email already associated with 2FA account #88287.

What alternative solutions did you explore? (Optional)

Adding a separate MERGE_ACCOUNT_2FA_ERROR_TITLE constant was considered but rejected: the closed-account precedent reuses one constant matched across multiple response fields, and keeping a single source of truth avoids drift if the backend tweaks one surface.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the onboarding "What's your work email?" step, entering a work email tied to an existing account that has 2FA enabled shows the generic blocking screen ("Couldn't add work email. We couldn't add… Please try again later in Settings…") instead of the specific 2FA message added in PR #88287.

What is the root cause of that problem?

In AddWorkEmail we only inspect response.message for the 2FA marker, while the very next check (WORK_ACCOUNT_CLOSED_ERROR) correctly inspects both response.message and response.title. When the backend returns the 2FA error in response.title (or message is empty/wrapped) the 2FA branch is skipped and we fall through to Onyx.merge(NVP_ONBOARDING, {isMergingAccountBlocked: true}), which renders OnboardingMergingAccountBlockedView with the generic mergeBlockScreen.subtitle — exactly the wording in the bug report.

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

Lines 1514 to 1517 in de3e3bf

	if (response?.message?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR)) {
	Onyx.merge(ONYXKEYS.ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY, 'onboarding.workEmail2FAError');
	return;
	}

What changes do you think we should make in order to solve the problem?

Make the 2FA check symmetric with the closed-account check by inspecting both response.message and response.title for CONST.MERGE_ACCOUNT_2FA_ERROR. Update the condition in AddWorkEmail so it reads roughly: if response?.message?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR) || response?.title?.includes(CONST.MERGE_ACCOUNT_2FA_ERROR), merge 'onboarding.workEmail2FAError' into ONYXKEYS.ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY and return — preventing the fallthrough that sets isMergingAccountBlocked. This is a one-line, single-file change in src/libs/actions/Session/index.ts and matches the pattern already used for WORK_ACCOUNT_CLOSED_ERROR two lines below.

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

Lines 1519 to 1523 in de3e3bf

	if (response?.message === CONST.WORK_ACCOUNT_CLOSED_ERROR || response?.title === CONST.WORK_ACCOUNT_CLOSED_ERROR) {
	Onyx.merge(ONYXKEYS.ONBOARDING_ERROR_MESSAGE_TRANSLATION_KEY, 'onboarding.mergeBlockScreen.workAccountClosedSubtitle');
	return;
	}
	Onyx.merge(ONYXKEYS.NVP_ONBOARDING, {isMergingAccountBlocked: true});

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @QichenZhu (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058788479476404717

[lxyct825-ops]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] Wrong error message after adding work email account with 2FA enabled

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

What changes do you think we should make in order to solve the problem?

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.