2FA - The ‘Invalid code’ error persists after closing and reopening the RHP

[lanitochka17]

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.36-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #79266
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 15.4.1 Safari/Chrome
App Component: User Settings

Action Performed:

1. Go to https://staging.new.expensify.com
2. Configure two-factor authentication
3. Go to Account > Security > Two-factor authentication
4. Press Replace device
5. Enter 6 random numbers, or all zeros
6. Observe an error message is displayed
7. Close the RHP
8. Click the Two-factor authentication
9. Press Replace device

Expected Result:

The ‘Invalid code’ error should be removed after closing and reopening the RHP

Actual Result:

The ‘Invalid code’ error persists after closing and reopening the RHP

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7100416_1773263511195.Recording__1768.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #79266

[melvin-bot]

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

[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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #79266 - "Create a flow to replace the user's two-factor device" by @chuckdries (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

A simple fix is available - the two new pages introduced by this PR need to add error cleanup logic that already exists in other 2FA pages. Rolling forward with a small patch is more efficient than reverting the entire feature.

Labels: No label changes - keeping DeployBlockerCash as this is a frontend bug affecting the App deploy.

Detailed Analysis

Evidence

• The issue specifically mentions that the error persists after closing and reopening the RHP during the "Replace device" flow
• PR Create a flow to replace the user's two-factor device #79266 introduced this entire feature, adding:
  • ReplaceDeviceVerifyOldPage.tsx
  • ReplaceDeviceVerifyNewPage.tsx
  • New routes and navigation for the replace device flow
• The issue is reproducible on staging where this PR is deployed, and the feature does not exist in production

Verification

Files affected:

• /home/runner/_work/App/App/src/pages/settings/Security/TwoFactorAuth/ReplaceDeviceVerifyOldPage.tsx
• /home/runner/_work/App/App/src/pages/settings/Security/TwoFactorAuth/ReplaceDeviceVerifyNewPage.tsx

PR #79266 created both files and introduced the replace device functionality.

Root Cause

Both ReplaceDeviceVerifyOldPage and ReplaceDeviceVerifyNewPage are missing the cleanup logic that clears account error messages when the component mounts/unmounts.

The existing VerifyPage.tsx (from the original 2FA enable flow) has this pattern:

useEffect(() => {
    clearAccountMessages();
    return () => {
        clearAccountMessages();
    };
}, []);

This ensures error messages stored in ONYXKEYS.ACCOUNT are cleared when entering the page. The new Replace Device pages only call clearAccountMessages() in response to input changes (clearAccountErrorsIfPresent), but not on page mount. Therefore, when the RHP is closed and reopened, the previous error persists.

Fix Required

Add the same useEffect cleanup hook to both Replace Device pages to clear errors on mount/unmount, matching the pattern in VerifyPage.tsx.

[MelvinBot]

Proposal

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

When a user enters an invalid code in the 2FA "Replace device" flow, an "Invalid code" error is displayed. If the user closes the RHP and reopens it, the error message persists instead of being cleared.

What is the root cause of that problem?

The error from a failed replaceTwoFactorDevice API call is stored in ONYXKEYS.ACCOUNT.errors. Neither ReplaceDeviceVerifyOldPage nor ReplaceDeviceVerifyNewPage clear this error on mount or unmount.

When the RHP closes, quitAndNavigateBack calls clearTwoFactorAuthData, which clears recoveryCodes, twoFactorAuthSecretKey, and codesAreCopied — but not errors (TwoFactorAuthActions.ts:11-18). So the stale error remains in Onyx and is immediately rendered when the page reopens.

The sibling VerifyPage already handles this correctly with a useEffect that calls clearAccountMessages() on both mount and unmount (VerifyPage.tsx:44-49). The Replace Device pages are missing this same pattern.

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

Add a useEffect to both ReplaceDeviceVerifyOldPage.tsx and ReplaceDeviceVerifyNewPage.tsx that calls clearAccountMessages() on mount and returns it as a cleanup function on unmount — the same pattern used by VerifyPage.tsx. Both files already import clearAccountMessages from @userActions/Session, so no new imports are needed.

What alternative solutions did you explore? (Optional)

An alternative would be to add errors: null to clearTwoFactorAuthData in TwoFactorAuthActions.ts. However, this is less robust because users can close the RHP by swiping or tapping outside it (bypassing the back button handler), and the useEffect cleanup approach covers all dismissal paths. The useEffect pattern also matches the established convention used by other 2FA pages in this codebase.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[chuckdries]

Eh, nobody is using that feature yet, we might as well revert tbh and I'll fix it on the next round