[$250] Troubleshoot - The Switch to Expensify Classic button is missing

[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.4.6-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: https://test-management.browserstack.com/projects/2219752/folder/13176927/test-cases/41237621?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 15.4.1 Safari
App Component: Other

Action Performed:

1. Go to https://staging.new.expensify.com
2. Go to Account > Troubleshoot

Expected Result:

The Switch to Expensify Classic button is present

Actual Result:

The Switch to Expensify Classic button is missing, it appears briefly after clearing cache

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7178408_1781223443960.Recording__2361.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7178408

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065232510229131926
• Upwork Job ID: 2065232510229131926
• Last Price Increase: 2026-06-12

Issue Owner

Current Issue Owner: @pecanoro

[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/643fc2f10aa6485fa8690c4d056436e65aa57a16bc173db3ab149bee51597afd

[MelvinBot]

Issue Analysis

Likely working as designed (Medium-High confidence). The "Switch to Expensify Classic" button is intentionally hidden on Troubleshoot for accounts that are locked to NewDot, or whose migration nudge is 30+ days stale. The brief flash-then-disappear after clearing cache is the tell: the button defaults to visible until the nvp_tryNewDot NVP loads, then hides once the gating value arrives from the server.

Mechanism:

• The menu item is gated by shouldHideOldAppRedirect(tryNewDot, isLoadingTryNewDot, CONFIG.IS_HYBRID_APP). When it returns true, getClassicRedirectMenuItem() returns null and the button is omitted.
• On web (Mac Safari/Chrome, IS_HYBRID_APP = false), shouldHideOldAppRedirect reduces to isLockedToNewDot === true || hasBeenInNewDot30Days(...). There is no loading guard on web, so the button renders by default while the NVP is empty, then hides once it loads — exactly the "appears briefly after clearing cache" symptom.
• The page calls openTroubleshootSettingsPage() on mount, which API.reads and populates nvp_tryNewDot with classicRedirect.isLockedToNewDot (or a stale nudge timestamp) → button correctly hidden.

This gating was added deliberately in April 2026 (Hide Classic redirects until tryNewDot loads, Hide Switch to Classic button when classicRedirect nudge is stale). So a missing button means the test account is locked to NewDot / past the 30-day window — the regression TC's "button is present" expectation is most likely stale.

Recommended next step (not a code fix): Verify the Applause test account's nvp_tryNewDot value. If classicRedirect.isLockedToNewDot === true or the nudge is 30+ days old, the hidden button is correct and the regression test case should be updated. Only if the button is hidden for an account that is not locked and has a fresh/absent nudge would this be a real bug.

Possible secondary UX concern

On web there is no isLoadingTryNewDot guard, so eligible-to-hide accounts see the button flash visible for one render before it disappears. If the brief flash itself is considered undesirable, the web path could also suppress the button while isLoadingTryNewDot is true (mirroring the HybridApp behavior). This is cosmetic — the end state (hidden button for locked accounts) is correct either way.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's analysis.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

Proposal

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

On web (Safari/Chrome on macOS) and iOS, navigating to Account → Troubleshoot does not render the "Switch to Expensify Classic" button. The button flashes briefly right after a cache clear and then disappears once Onyx hydrates. Expected: the button should be present on the Troubleshoot page so the user can manually switch back to Expensify Classic.

What is the root cause of that problem?

PR #88393 added hasBeenInNewDot30Days and wired it into isOldAppRedirectBlocked at src/libs/TryNewDotUtils.ts:31. That predicate returns true whenever tryNewDot.classicRedirect.dismissed === false and the nudge timestamp is ≥30 days old. TroubleshootPage.tsx:123 calls shouldHideOldAppRedirect(...) (which delegates to isOldAppRedirectBlocked at TryNewDotUtils.ts:35) to decide whether to render the "Switch to Expensify Classic" menu item. For any tester who has been in NewDot for over 30 days with an un-dismissed nudge, the new 30-day branch now hides the manual button as well — but that 30-day rule was only meant to suppress the automatic redirect to OldDot, not the manual opt-out on the Troubleshoot page. The brief appearance after cache clear matches the load order: before Onyx hydrates tryNewDot, classicRedirect is undefined, so hasBeenInNewDot30Days returns false and the button renders; once hydration completes the new branch fires and the button disappears.

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

1. src/libs/TryNewDotUtils.ts:30-32 — Stop folding hasBeenInNewDot30Days into the generic isOldAppRedirectBlocked predicate. Keep isOldAppRedirectBlocked returning only classicRedirect.isLockedToNewDot === true || (shouldRespectMobileLock && isLockedToNewApp(...)), which restores the pre-PR-88393 behavior for callers that gate the manual Classic button.
2. src/libs/TryNewDotUtils.ts — Apply the 30-day suppression only to the automatic redirect path. Either (a) add a dedicated helper (e.g. shouldAutoRedirectToOldDot) that ORs hasBeenInNewDot30Days in, and use it only at the auto-redirect call site, or (b) add a boolean parameter to shouldHideOldAppRedirect so only auto-redirect callers opt into the 30-day rule.
3. src/pages/settings/Troubleshoot/TroubleshootPage.tsx:123, src/pages/settings/InitialSettingsPage.tsx:365, src/pages/settings/Security/TwoFactorAuth/SuccessPage.tsx:15, src/pages/settings/Security/TwoFactorAuth/DynamicSuccessPage.tsx:38, src/pages/settings/Security/MergeAccounts/MergeResultPage.tsx:44, src/components/ScreenWrapper/index.tsx:185 — Audit each consumer of shouldHideOldAppRedirect and confirm the manual "Switch to Expensify Classic" entry points (Troubleshoot, InitialSettings) do NOT opt into the 30-day suppression. Only the auto-redirect-on-launch path should.
4. tests/unit/TryNewDotUtilsTest.ts — Add a regression test asserting that with dismissed: false and a 31-day-old timestamp, the manual Classic button predicate still returns "show button"; keep the existing tests for the auto-redirect path under the renamed/new helper.

What alternative solutions did you explore? (Optional)

Gating the 30-day suppression behind shouldRespectMobileLock was considered, but that flag is CONFIG.IS_HYBRID_APP and overloads an unrelated concept; introducing a dedicated auto-redirect predicate is clearer.

[MarcosProWork]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[lorretheboy]

Proposal

What is the root cause of that problem?

On the Troubleshoot page the menu item is built by getClassicRedirectMenuItem, which returns null (hiding the button) whenever shouldHideOldAppRedirect is true:

App/src/pages/settings/Troubleshoot/TroubleshootPage.tsx

Lines 122 to 125 in 23e38e8

	const getClassicRedirectMenuItem = (): BaseMenuItem | null => {
	if (shouldHideOldAppRedirect(tryNewDot, isLoadingTryNewDot, CONFIG.IS_HYBRID_APP)) {
	return null;
	}

shouldHideOldAppRedirect delegates to isOldAppRedirectBlocked, which is true when the user is locked or when hasBeenInNewDot30Days is true:

App/src/libs/TryNewDotUtils.ts

Lines 30 to 36 in 23e38e8

	function isOldAppRedirectBlocked(tryNewDot: OnyxEntry<TryNewDot>, shouldRespectMobileLock: boolean): boolean {
	return tryNewDot?.classicRedirect?.isLockedToNewDot === true || hasBeenInNewDot30Days(tryNewDot) || (shouldRespectMobileLock && isLockedToNewApp(tryNewDot));
	}
	function shouldHideOldAppRedirect(tryNewDot: OnyxEntry<TryNewDot>, isLoadingTryNewDot: boolean, shouldRespectMobileLock: boolean): boolean {
	return (shouldRespectMobileLock && isLoadingTryNewDot) || isOldAppRedirectBlocked(tryNewDot, shouldRespectMobileLock);
	}

hasBeenInNewDot30Days returns true for any user whose classicRedirect nudge has dismissed === false and a timestamp older than 30 days:

App/src/libs/TryNewDotUtils.ts

Lines 12 to 20 in 23e38e8

	function hasBeenInNewDot30Days(tryNewDot: OnyxEntry<TryNewDot>): boolean {
	const classicRedirect = tryNewDot?.classicRedirect;
	if (!classicRedirect || classicRedirect.dismissed !== false || !classicRedirect.timestamp) {
	return false;
	}
	const daysSinceNudge = differenceInDays(new Date(), new Date(classicRedirect.timestamp));
	return daysSinceNudge >= NEW_DOT_MIN_DAYS_BEFORE_HIDING_CLASSIC_REDIRECT;
	}

Causal chain: the nudge timestamp is stamped once when the user first lands in NewDot and is never refreshed → every established NewDot user (which is every regression tester) is past 30 days with dismissed === false → hasBeenInNewDot30Days → isOldAppRedirectBlocked → shouldHideOldAppRedirect is true → the Troubleshoot item is dropped. After a cache clear tryNewDot is momentarily empty so none of these conditions hold and the button flashes in, then disappears once the NVP loads — exactly the reported symptom.

The deeper problem is the level: hiding the redirect after the nudge goes stale is correct for the nudge entry point, but the Troubleshoot page button is a deliberate manual escape hatch and should not be removed just because the nudge aged out.

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

Stop gating the Troubleshoot escape hatch on the 30-day nudge-staleness rule. It should be hidden only for users who are genuinely locked (classicRedirect.isLockedToNewDot, and on HybridApp the mobile isLockedToNewApp lock + the loading guard) — not because of hasBeenInNewDot30Days.

Concretely, give getClassicRedirectMenuItem its own check that excludes the staleness branch (e.g. a helper that drops hasBeenInNewDot30Days from this line):

App/src/libs/TryNewDotUtils.ts

Line 31 in 23e38e8

return tryNewDot?.classicRedirect?.isLockedToNewDot === true || hasBeenInNewDot30Days(tryNewDot) || (shouldRespectMobileLock && isLockedToNewApp(tryNewDot));

The other call site, InitialSettingsPage, intentionally keeps the staleness hide and is additionally gated on nudgeMigration, so it should keep the current shouldHideOldAppRedirect behavior:

App/src/pages/settings/InitialSettingsPage.tsx

Line 365 in 23e38e8

if (!shouldHideOldAppRedirect(tryNewDot, isLoadingTryNewDot, CONFIG.IS_HYBRID_APP)) {

What alternative solutions did you explore? (Optional)

If product intends the redirect to truly disappear everywhere after 30 days, the fix is instead to refresh classicRedirect.timestamp on continued NewDot usage (or treat it as a one-shot nudge flag rather than an ever-growing age), so long-time users aren't permanently treated as "stale" and stripped of the switch.