[$250] No reason and confirm pages open when user switch to Expensify Classic

[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: 9.3.61-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: #86767
Email or phone of affected tester (no customers): fischer9966+042126aa@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 17 Pro / 26.4.1
App Component: User Settings

Action Performed:

1. Open the Expensify App
2. Login with new account
3. Tap on "Accounts" > "Troubleshoot"
4. Tap on "Switch to Expensify Classic"
5. Enter the reason and click on "Next".
6. It should open the Confirm page.

Expected Result:

Reason page and then Confirm page opens when user select "Switch to Expensify Classic" flow

Actual Result:

User switch to Expensify Classic without reason and confirm pages for the first time in new account

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134990_1776783728498.86767-iOS.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jjcoffee

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046897237173396117
• Upwork Job ID: 2046897237173396117
• Last Price Increase: 2026-04-22

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

In TroubleshootPage.tsx:72 (and identically in InitialSettingsPage.tsx:322), the condition that decides whether to show the exit survey reason page is:

const shouldOpenSurveyReasonPage = tryNewDot?.classicRedirect?.dismissed === false;

For new accounts, tryNewDot is empty/undefined, so classicRedirect?.dismissed is undefined. Since undefined === false evaluates to false, the reason page is skipped entirely. Navigation goes straight to EXIT_SURVEY_CONFIRM, which then shows a "quick tips" variant (because shouldShowQuickTips is true when tryNewDot is empty at DynamicExitSurveyConfirmPage.tsx:40-41), letting the user switch to Classic without ever seeing the survey.

The strict === false check was designed for users migrated from OldDot (where dismissed is explicitly set to false), but it excludes new accounts where the field simply doesn't exist.

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

Change the condition in both TroubleshootPage.tsx:72 and InitialSettingsPage.tsx:322 from:

tryNewDot?.classicRedirect?.dismissed === false

to:

tryNewDot?.classicRedirect?.dismissed !== true

This ensures the reason page is shown for both migrated users (dismissed === false) and new accounts (dismissed === undefined), only skipping it when the user has already been through the flow and dismissed is explicitly true.

Similarly, the shouldShowQuickTips logic in DynamicExitSurveyConfirmPage.tsx:40-41 should be updated to only show quick tips when dismissed === true (i.e., users who have already completed the survey), not when tryNewDot is empty.

What alternative solutions did you explore? (Optional)

An alternative would be to explicitly initialize classicRedirect.dismissed to false for new accounts during onboarding. However, this is more invasive and would require a backend/Onyx change, whereas the condition fix is a minimal frontend-only change that correctly handles all three states (true, false, undefined).

---

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.

[huult]

@mananjadhav Could you check this issue? It seems not related to our migration.