[$250] Clear cache & refresh goes to Humm It's not here page

[m-natarajan]

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

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @sakluger
Slack conversation (hyperlinked to channel name): #Expensify bugs

Action Performed:

1. Navigate to Accounts > Troubleshoot > Clear cache and restart
2. Click Reset and refresh on the modal

Expected Result:

Page refreshed and loads without any issue

Actual Result:

Hmm its not here page displayed

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The video for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072400540259536083
• Upwork Job ID: 2072400540259536083
• Last Price Increase: 2026-07-01

[MelvinBot]

Proposal

What is the root cause of that problem?

Clearing the cache wipes the report collection from Onyx, but the report the user was viewing stays mounted in the central pane underneath the Settings > Troubleshoot RHP. That central pane's not-found guard then sees "report gone + app not loading" and renders the "Hmm... it's not here" page.

Two things unique to this flow cause it:

1. Troubleshoot doesn't navigate home after resetting. TroubleshootPage.tsx:87 calls clearOnyxAndResetApp() with no argument, so shouldNavigateToHomepage is falsy and the navigate-to-HOME branch is skipped. The stale report route stays mounted. (Contrast the other caller, ImportedStateIndicator.tsx:27, which calls clearOnyxAndResetApp(true) and navigates away — it never hits this bug.)

2. IS_LOADING_APP is preserved as false during the wipe. It's in KEYS_TO_PRESERVE, so clearOnyxAndSeedFullReconnect keeps its pre-clear value of false. openApp() only flips it back to true in a later .then() (after the web-only clearWorkboxRecoveryCaches() step). In that window, the not-found guard evaluates with report data gone AND the app looking "not loading".

The guard, ReportNotFoundGuard.tsx:50,68: isLoading is false (because isLoadingApp === false), reportExists is false (report wiped), and hasSeenLoadingForCurrentReportID was already true from the original load → shouldShowNotFoundPage = true.

This is why it's web-only and intermittent: clearWorkboxRecoveryCaches() (a web service-worker step) widens the timing window before openApp() seeds IS_LOADING_APP=true.

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

Either one closes the window:

• Simplest: have Troubleshoot call clearOnyxAndResetApp(true) so it navigates to HOME after the reset, matching ImportedStateIndicator and replacing the now-invalid report route. (TroubleshootPage.tsx:87)
• More robust: seed IS_LOADING_APP = true into the clear inside clearOnyxAndResetApp (via extraSeeds) so the not-found guard sees the app as loading across the entire clear → openApp window, regardless of which route is mounted. (App.ts:881)

The second option also protects other central-pane guards (e.g. workspace AccessOrNotFoundWrapper after policies are wiped), so it's the safer fix.

Investigation details & confidence

Data flow: viewing a report → open Settings > Troubleshoot (RHP over the report) → confirm "Reset and refresh" → clearOnyxAndResetApp() with no arg → Navigation.clearPreloadedRoutes() + Onyx clear wipes report collection but preserves IS_LOADING_APP=false → ReportNotFoundGuard re-renders with reportExists=false, isLoading=false, hasSeenLoadingForCurrentReportID=true → FullPageNotFoundView shouldShow renders "Hmm... it's not here" (string notFound.notHere in en.ts) → openApp() later sets IS_LOADING_APP=true, but the not-found page has already committed and, since the route was never changed, the app can be left on it.

Confidence: High on the mechanism (code ordering proves the window exists). Medium on how often it reproduces — the window width is timing/render-commit dependent, which matches the "Needs Reproduction / unable to reproduce" status. Production confirmation would come from the [ReportScreen] Displaying NotFound Page log line (ReportNotFoundGuard.tsx:73) correlated with an OpenApp on web.

Alternative considered: if the visible central pane at reset time isn't a report (e.g. a workspace settings page), the same symptom can come from AccessOrNotFoundWrapper after policies are wiped — same root cause (stale route + preserved loading flag), which is why the extraSeeds fix is preferable.

---

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

[aswin-s]

Proposal

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

On Web (Chrome/Safari on macOS, Chrome on Windows), navigating to Accounts > Troubleshoot > Clear cache and restart and clicking "Reset and refresh" lands the user on the "Hmm, it's not here" (NotFound) page instead of refreshing the current page and loading normally.

What is the root cause of that problem?

In src/pages/settings/Troubleshoot/TroubleshootPage.tsx:87, showResetAndRefreshModal invokes clearOnyxAndResetApp() with no arguments. In src/libs/actions/App.ts:881-905, clearOnyxAndResetApp(shouldNavigateToHomepage?) only navigates to ROUTES.HOME when shouldNavigateToHomepage is truthy (line 903). Because the caller omits the flag, after Navigation.clearPreloadedRoutes() (line 887) fires and Onyx is wiped, the user is left on the deep /settings/troubleshoot route with cleared state and no navigation home, so the router falls through to the NotFound ("Hmm, it's not here") page.

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

1. src/pages/settings/Troubleshoot/TroubleshootPage.tsx:87 — pass true for shouldNavigateToHomepage: clearOnyxAndResetApp(true); so the user is routed to ROUTES.HOME after the Onyx reset completes.
2. Alternatively (or additionally), change the default in src/libs/actions/App.ts:881 so shouldNavigateToHomepage defaults to true (all callers that trigger a full reset should return to home after the state wipe).
3. Verify other callers of clearOnyxAndResetApp (e.g., src/libs/actions/App.ts:188) still behave correctly with the chosen default; adjust their argument if needed.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-01 19:25:07 UTC.

Proposal

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

Running Settings → Troubleshoot → Clear cache and restart → Reset and refresh drops the user on the "Hmm... it's not here" (not found) page instead of quietly refreshing the app.

What is the root cause of that problem?

The two call sites that trigger a cache reset diverge — one navigates the user to a safe route afterwards, the other does not.

1. The reset handler on the Troubleshoot page calls clearOnyxAndResetApp() with no argument:
   

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

   Lines 85 to 87 in e4b4a90

   	resetOptions();
   	setShouldResetSearchQuery(true);
   	clearOnyxAndResetApp();

2. clearOnyxAndResetApp only navigates home when its optional shouldNavigateToHomepage flag is truthy. Called with no arg, that branch is skipped, so navigation stays exactly where it was while Onyx is wiped and re-fetched:
   

   App/src/libs/actions/App.ts

   Lines 881 to 905 in e4b4a90

   	function clearOnyxAndResetApp(shouldNavigateToHomepage?: boolean) {
   	// The value of isUsingImportedState will be lost once Onyx is cleared, so we need to store it
   	const isStateImported = isUsingImportedState;
   	rollbackOngoingRequest();
   	const sequentialQueue = getAll();
   	Navigation.clearPreloadedRoutes();
   	// Seed LAST_FULL_RECONNECT_TIME so subscribeToFullReconnect doesn't fire a duplicate
   	// ReconnectApp once the openApp() below lands NVP_RECONNECT_APP_IF_FULL_RECONNECT_BEFORE.
   	const resetPromise = clearWorkboxRecoveryCaches().then(() =>
   	clearOnyxAndSeedFullReconnect(KEYS_TO_PRESERVE)
   	.then(() => {
   	// Network key is preserved, so when exiting imported state, we should:
   	// 1. Stop forcing offline mode so the app can reconnect
   	// 2. Clear the IS_USING_IMPORTED_STATE flag
   	// 3. Restore the original user session
   	if (isStateImported) {
   	setShouldForceOffline(false);
   	Onyx.set(ONYXKEYS.IS_USING_IMPORTED_STATE, false);
   	Log.info('[ImportedState] Exiting imported state mode, restoring original session');
   	}
   	if (shouldNavigateToHomepage) {
   	Navigation.navigate(ROUTES.HOME);
   	}

3. The reset clears every Onyx collection and then kicks off openApp to reload it. During that clear→reload window the route the user is sitting on (and the report/central‑pane route it sits over) has no data. IS_LOADING_APP is intentionally preserved across the clear (it is in KEYS_TO_PRESERVE), so it stays false — i.e. "not loading" — even though the data is momentarily gone:
   

   App/src/libs/actions/App.ts

   Lines 147 to 172 in e4b4a90

   	const KEYS_TO_PRESERVE: OnyxKey[] = [
   	ONYXKEYS.ACCOUNT,
   	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
   	ONYXKEYS.IS_LOADING_APP,
   	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
   	ONYXKEYS.MODAL,
   	ONYXKEYS.NETWORK,
   	ONYXKEYS.SESSION,
   	ONYXKEYS.NVP_TRY_FOCUS_MODE,
   	ONYXKEYS.PREFERRED_THEME,
   	ONYXKEYS.SIGN_IN_HIGH_CONTRAST_INTENT,
   	ONYXKEYS.NVP_PREFERRED_LOCALE,
   	ONYXKEYS.CREDENTIALS,
   	ONYXKEYS.PRESERVED_USER_SESSION,
   	ONYXKEYS.PRESERVED_ACCOUNT,
   	ONYXKEYS.HYBRID_APP,
   	ONYXKEYS.SHOULD_USE_STAGING_SERVER,
   	ONYXKEYS.IS_DEBUG_MODE_ENABLED,
   	ONYXKEYS.COLLECTION.PASSKEY_CREDENTIALS,
   	ONYXKEYS.COLLECTION.DEVICE_BIOMETRICS,
   	ONYXKEYS.STASHED_SESSION,
   	ONYXKEYS.STASHED_CREDENTIALS,
   	// Preserve IS_USING_IMPORTED_STATE so that when the app restarts (especially in HybridApp mode),
   	// we know if we're in imported state mode and should skip API calls that would cause infinite loading
   	ONYXKEYS.IS_USING_IMPORTED_STATE,

4. With "loading" reading false and the report/collection empty, the not‑found gate flips true and renders FullPageNotFoundView, whose default title is the exact notFound.notHere = "Hmm... it's not here" string from the report:
   

   App/src/pages/inbox/ReportNotFoundGuard.tsx

   Lines 50 to 68 in e4b4a90

   	const isLoading = isLoadingApp !== false || isLoadingReportData || (!isOffline && !!isLoadingInitialReportActions);
   	const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
   	// `isLoadingInitialReportActions` lives in a memory-only key that is not reset between navigations.
   	// Returning to a previously visited report (e.g. via direct URL) can leave a stale `false` here, so we
   	// only infer not-found once we've actually observed a loading phase for the current reportID — i.e. a
   	// fetch was in flight — instead of trusting the leaked flag. See issue #92920.
   	// This uses the documented "adjust state during render" pattern to keep the gate render-synchronous.
   	const [trackedReportID, setTrackedReportID] = useState(reportIDFromRoute);
   	const [hasSeenLoadingForCurrentReportID, setHasSeenLoadingForCurrentReportID] = useState(false);
   	if (trackedReportID !== reportIDFromRoute) {
   	setTrackedReportID(reportIDFromRoute);
   	setHasSeenLoadingForCurrentReportID(false);
   	}
   	if (isLoading && !hasSeenLoadingForCurrentReportID) {
   	setHasSeenLoadingForCurrentReportID(true);
   	}
   	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && hasSeenLoadingForCurrentReportID && !reportExists));

   
   

   App/src/components/BlockingViews/FullPageNotFoundView.tsx

   Lines 65 to 70 in e4b4a90

   	function FullPageNotFoundView({
   	testID,
   	children = null,
   	shouldShow = false,
   	titleKey = 'notFound.notHere',

The working sibling — the "using imported state" banner — resets in the same way but passes true, so it lands the user on the resilient HOME route (which has no full‑page not‑found gate) while data reloads:

App/src/components/ImportedStateIndicator.tsx

Line 27 in e4b4a90

onPress={() => clearOnyxAndResetApp(true)}

So the structural cause is that the Troubleshoot reset abandons the user on a route that is temporarily unresolvable, instead of resetting navigation to a safe base like the identical imported‑state flow already does. This is timing‑dependent, which is why it is intermittent / "unable to reproduce".

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

Make the Troubleshoot reset match the imported‑state sibling — pass shouldNavigateToHomepage = true so the user is moved to HOME before the reloaded data settles, instead of watching a stale route resolve to not‑found:

// src/pages/settings/Troubleshoot/TroubleshootPage.tsx
resetOptions();
setShouldResetSearchQuery(true);
clearOnyxAndResetApp(true);

Regression safety: the argument is additive and defaulted, so the only other real caller — ImportedStateIndicator (already true) and the RESET_REQUIRED emergency listener — are untouched; a "restart" landing on Home is the expected behavior of a full reset.

Why the obvious fix does not work: the tempting alternative is to make the not‑found gate wait on IS_LOADING_APP (treat the reset as "still loading"). That fails because IS_LOADING_APP is deliberately kept in KEYS_TO_PRESERVE — it was put there by Revert IS_LOADING_APP RAM-only migration to fix LHN infinite loading on offline refresh — so it stays false across the clear on purpose. Loosening the gate on that flag re‑introduces the offline‑refresh LHN infinite‑loading it was added to fix. Moving navigation to a safe route sidesteps the empty‑data window entirely without touching that flag.

What alternative solutions did you explore? (Optional)

• Reset IS_LOADING_APP to true during the clear so every not‑found gate suppresses until openApp finishes. Rejected: it fights the intentional preserve above and risks the offline LHN infinite‑loading regression.
• Keep the user on /settings/troubleshoot but block the underlying route with a loading state until openApp resolves. More surface area and still leaves navigation pointed at a route whose data was wiped; the sibling‑parity navigate‑home fix is the minimal, precedent‑backed change.

[oqildev]

Proposal

What is the root cause of that problem?

The "Reset and refresh" button runs this, in order, from the Troubleshoot page:

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

Lines 74 to 88 in e4b4a90

	const showResetAndRefreshModal = async () => {
	const result = await showConfirmModal({
	title: translate('common.areYouSure'),
	prompt: translate('initialSettingsPage.troubleshoot.confirmResetDescription'),
	confirmText: translate('initialSettingsPage.troubleshoot.resetAndRefresh'),
	cancelText: translate('common.cancel'),
	shouldShowCancelButton: true,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	resetOptions();
	setShouldResetSearchQuery(true);
	clearOnyxAndResetApp();
	};

clearOnyxAndResetApp() wipes Onyx (keeping only the entries in KEYS_TO_PRESERVE) and then re-fetches everything with OpenApp. Two things about that preserve list matter here:

App/src/libs/actions/App.ts

Lines 147 to 173 in e4b4a90

	const KEYS_TO_PRESERVE: OnyxKey[] = [
	ONYXKEYS.ACCOUNT,
	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
	ONYXKEYS.IS_LOADING_APP,
	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
	ONYXKEYS.MODAL,
	ONYXKEYS.NETWORK,
	ONYXKEYS.SESSION,
	ONYXKEYS.NVP_TRY_FOCUS_MODE,
	ONYXKEYS.PREFERRED_THEME,
	ONYXKEYS.SIGN_IN_HIGH_CONTRAST_INTENT,
	ONYXKEYS.NVP_PREFERRED_LOCALE,
	ONYXKEYS.CREDENTIALS,
	ONYXKEYS.PRESERVED_USER_SESSION,
	ONYXKEYS.PRESERVED_ACCOUNT,
	ONYXKEYS.HYBRID_APP,
	ONYXKEYS.SHOULD_USE_STAGING_SERVER,
	ONYXKEYS.IS_DEBUG_MODE_ENABLED,
	ONYXKEYS.COLLECTION.PASSKEY_CREDENTIALS,
	ONYXKEYS.COLLECTION.DEVICE_BIOMETRICS,
	ONYXKEYS.STASHED_SESSION,
	ONYXKEYS.STASHED_CREDENTIALS,
	// Preserve IS_USING_IMPORTED_STATE so that when the app restarts (especially in HybridApp mode),
	// we know if we're in imported state mode and should skip API calls that would cause infinite loading
	ONYXKEYS.IS_USING_IMPORTED_STATE,
	];

ONYXKEYS.IS_LOADING_APP is preserved, but ONYXKEYS.HAS_LOADED_APP is not. So immediately after the clear, the report/policy collections are empty, HAS_LOADED_APP is undefined, and IS_LOADING_APP still holds its stale pre-clear value of false. IS_LOADING_APP only flips back to true once OpenApp's optimistic data is applied:

App/src/libs/actions/App.ts

Lines 364 to 376 in e4b4a90

	if (isOpenApp) {
	result.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.IS_LOADING_APP,
	value: true,
	});
	result.finallyData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.IS_LOADING_APP,
	value: false,
	});
	}

On web this is a "restart" — the reset path clears the service worker/cache storage (web-only; the helper early-returns on native) and reloads the tab:

App/src/libs/clearWorkboxRecoveryCaches/index.ts

Lines 10 to 20 in e4b4a90

	async function clearWorkboxRecoveryCaches(): Promise<void> {
	// Normally platform-specific behaviour is achieved with .native.ts / .ts file pairs.
	// A .native.ts stub was tried here but the Jest test environment (jsdom, testEnvironment
	// in jest.config.js) resolves both web and native imports to the same .ts file, so the
	// stub was ignored and the test called real Cache Storage / ServiceWorker APIs that don't
	// exist in jsdom, breaking the clearOnyxAndResetApp test. An explicit Platform.OS guard
	// keeps the code in a single file while being safe in all three environments:
	// web (browser), native (iOS/Android), and the Jest jsdom test runner.
	if (Platform.OS !== 'web') {
	return;
	}

That reload is why the page "goes" somewhere instead of staying on Troubleshoot: RHP/modal routes aren't restored across a hard reload, so the app comes back on the central-pane route (the previously open report or Search), not on the Troubleshoot RHP. That central page renders against a freshly-emptied Onyx while OpenApp is still in flight, and because IS_LOADING_APP is stuck at false there's no "still loading" signal — the page's not-found guard resolves to "not found" and shows FullPageNotFoundView ("Hmm… it's not here"). Once OpenApp returns and repopulates the collections it corrects itself, which is exactly why this is intermittent and hard to reproduce — it's a visible window, not a permanent state.

(I couldn't read the exact clearOnyxAndResetApp body in the provided slice of App.ts, but the preserve list, the clearWorkboxRecoveryCaches import in that file, and OpenApp's loading-flag timing pin the window down.)

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

Data layer — keep the app in a "loading" state across the reset so restored full-screen pages render a skeleton instead of the not-found page during the empty-Onyx window.

The simplest fix is to set ONYXKEYS.IS_LOADING_APP to true synchronously before clearOnyxAndResetApp() runs in showResetAndRefreshModal (IS_LOADING_APP is already in KEYS_TO_PRESERVE, so it survives the clear). OpenApp's finallyData already resets it to false when the fetch completes, so no other cleanup is needed. That closes the gap where a destination page sees isLoadingApp === false with empty collections.

The edge case this touches is only the transient post-clear render — offline behavior and optimistic rollback are unaffected because we're just holding the loading flag until OpenApp resolves (and offline reset already can't complete OpenApp, so the loading state is the honest state anyway).

What alternative solutions did you explore? (Optional)

Add ONYXKEYS.HAS_LOADED_APP to KEYS_TO_PRESERVE so it isn't wiped. Rejected: preserving HAS_LOADED_APP === true across a full data wipe is worse — it tells the rest of the app the (now-empty) data is fully loaded, which would make the not-found flash permanent on any page that keys off hasLoadedApp rather than transient. The loading-flag approach is the correct direction.

Also considered gating FullPageNotFoundView inside each restored central page on isLoadingApp. Rejected as the primary fix: that's the same missing-loading-signal problem spread across many call sites, and it only works if IS_LOADING_APP is actually true during the window — which it isn't today. Fixing the flag at the reset source is one change instead of N.

[lorretheboy]

Proposal

What is the root cause of that problem?

"Reset and refresh" calls clearOnyxAndResetApp() with no argument:

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

Lines 85 to 87 in e4b4a90

	resetOptions();
	setShouldResetSearchQuery(true);
	clearOnyxAndResetApp();

That function only navigates the user to a safe route when shouldNavigateToHomepage is passed, and Troubleshoot never passes it:

App/src/libs/actions/App.ts

Lines 881 to 905 in e4b4a90

	function clearOnyxAndResetApp(shouldNavigateToHomepage?: boolean) {
	// The value of isUsingImportedState will be lost once Onyx is cleared, so we need to store it
	const isStateImported = isUsingImportedState;
	rollbackOngoingRequest();
	const sequentialQueue = getAll();
	Navigation.clearPreloadedRoutes();
	// Seed LAST_FULL_RECONNECT_TIME so subscribeToFullReconnect doesn't fire a duplicate
	// ReconnectApp once the openApp() below lands NVP_RECONNECT_APP_IF_FULL_RECONNECT_BEFORE.
	const resetPromise = clearWorkboxRecoveryCaches().then(() =>
	clearOnyxAndSeedFullReconnect(KEYS_TO_PRESERVE)
	.then(() => {
	// Network key is preserved, so when exiting imported state, we should:
	// 1. Stop forcing offline mode so the app can reconnect
	// 2. Clear the IS_USING_IMPORTED_STATE flag
	// 3. Restore the original user session
	if (isStateImported) {
	setShouldForceOffline(false);
	Onyx.set(ONYXKEYS.IS_USING_IMPORTED_STATE, false);
	Log.info('[ImportedState] Exiting imported state mode, restoring original session');
	}
	if (shouldNavigateToHomepage) {
	Navigation.navigate(ROUTES.HOME);
	}

So the causal chain is: the reset wipes Onyx and calls Navigation.clearPreloadedRoutes() while the user is left sitting on the deep /settings/troubleshoot route (over the previously‑open report/central pane) → every report, policy and personal‑detail record is now empty and the preloaded routes are gone → the still‑mounted screen re‑resolves against empty state during the openApp reload window and shouldShow flips true on a FullPageNotFoundView, whose default title is notFound.notHere ("Hmm... it's not here"):

App/src/components/BlockingViews/FullPageNotFoundView.tsx

Lines 66 to 71 in e4b4a90

	function FullPageNotFoundView({
	testID,
	children = null,
	shouldShow = false,
	titleKey = 'notFound.notHere',
	subtitleKey = 'notFound.pageNotFound',

Because it depends on how quickly openApp re‑hydrates the current route, it only appears intermittently (hence "unable to reproduce" on fast staging).

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

Have the Troubleshoot reset send the user to a route that always renders correctly against empty/loading state, exactly like the imported‑state reset already does. Pass shouldNavigateToHomepage so the reset navigates to ROUTES.HOME before the re‑fetch:

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

Line 87 in e4b4a90

clearOnyxAndResetApp();

i.e. call clearOnyxAndResetApp(true). This mirrors the existing working call site:

App/src/components/ImportedStateIndicator.tsx

Line 27 in e4b4a90

onPress={() => clearOnyxAndResetApp(true)}

The Home/inbox screen shows loaders while openApp re‑hydrates instead of a not‑found, so the page reloads cleanly.

What alternative solutions did you explore? (Optional)

Make navigating to a safe route the default behavior of clearOnyxAndResetApp (navigate to ROUTES.HOME unconditionally after the Onyx clear resolves) so every reset entry point is protected, rather than depending on each caller remembering to pass the flag.

[abbasifaizan70]

Proposal

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

When a user navigates to Settings > Troubleshoot and clicks "Reset and refresh" in the confirmation modal, the app clears the Onyx cache and reloads app data, but instead of returning to a working page, the user is shown the "Hmm...it's not here" (Not Found) page.

What is the root cause of that problem?

TroubleshootPage's reset handler calls clearOnyxAndResetApp() with no argument, so the user is left on whatever route/report was active before the reset (e.g. a report behind the Settings RHP) instead of being sent to the app's home route.

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

Lines 74 to 88 in 252374e

	const showResetAndRefreshModal = async () => {
	const result = await showConfirmModal({
	title: translate('common.areYouSure'),
	prompt: translate('initialSettingsPage.troubleshoot.confirmResetDescription'),
	confirmText: translate('initialSettingsPage.troubleshoot.resetAndRefresh'),
	cancelText: translate('common.cancel'),
	shouldShowCancelButton: true,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	resetOptions();
	setShouldResetSearchQuery(true);
	clearOnyxAndResetApp();
	};

clearOnyxAndResetApp only navigates to ROUTES.HOME when its shouldNavigateToHomepage parameter is truthy. Since the Troubleshoot page never passes it, this branch is skipped, so the previously active route/report stays mounted while all of its underlying Onyx data (reports, report actions, etc.) has just been wiped and is being re-fetched from scratch via openApp().

App/src/libs/actions/App.ts

Lines 881 to 905 in 252374e

	function clearOnyxAndResetApp(shouldNavigateToHomepage?: boolean) {
	// The value of isUsingImportedState will be lost once Onyx is cleared, so we need to store it
	const isStateImported = isUsingImportedState;
	rollbackOngoingRequest();
	const sequentialQueue = getAll();
	Navigation.clearPreloadedRoutes();
	// Seed LAST_FULL_RECONNECT_TIME so subscribeToFullReconnect doesn't fire a duplicate
	// ReconnectApp once the openApp() below lands NVP_RECONNECT_APP_IF_FULL_RECONNECT_BEFORE.
	const resetPromise = clearWorkboxRecoveryCaches().then(() =>
	clearOnyxAndSeedFullReconnect(KEYS_TO_PRESERVE)
	.then(() => {
	// Network key is preserved, so when exiting imported state, we should:
	// 1. Stop forcing offline mode so the app can reconnect
	// 2. Clear the IS_USING_IMPORTED_STATE flag
	// 3. Restore the original user session
	if (isStateImported) {
	setShouldForceOffline(false);
	Onyx.set(ONYXKEYS.IS_USING_IMPORTED_STATE, false);
	Log.info('[ImportedState] Exiting imported state mode, restoring original session');
	}
	if (shouldNavigateToHomepage) {
	Navigation.navigate(ROUTES.HOME);
	}

Because the screen the user was on before the reset keeps rendering against the now-cleared/rebuilding cache (e.g. ReportNotFoundGuard sees a missing report for the still-mounted reportID), the guard resolves to "not found" and the "Hmm...it's not here" page is displayed. Notably, the only other caller of this same function, ImportedStateIndicator, already passes true to avoid exactly this problem:

App/src/components/ImportedStateIndicator.tsx

Line 27 in 252374e

onPress={() => clearOnyxAndResetApp(true)}

This confirms the Troubleshoot page's call site is simply missing the same shouldNavigateToHomepage argument, causing it to skip the safe redirect to home before/while the cache is rebuilt.

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

Pass true for shouldNavigateToHomepage when resetting from the Troubleshoot page, matching the existing safe usage in ImportedStateIndicator, so the user lands on ROUTES.HOME instead of remaining on a route whose backing data was just cleared.

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

Line 87 in 252374e

clearOnyxAndResetApp();

clearOnyxAndResetApp(true);

[kitvasyl]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The Troubleshoot page confirms "Reset and refresh" and then calls clearOnyxAndResetApp() without the existing homepage navigation flag. That means the destructive reset clears local app state and starts reopening app data while the user remains on the /settings/troubleshoot route that initiated the reset.

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

Lines 74 to 88 in e4b4a90

	const showResetAndRefreshModal = async () => {
	const result = await showConfirmModal({
	title: translate('common.areYouSure'),
	prompt: translate('initialSettingsPage.troubleshoot.confirmResetDescription'),
	confirmText: translate('initialSettingsPage.troubleshoot.resetAndRefresh'),
	cancelText: translate('common.cancel'),
	shouldShowCancelButton: true,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	resetOptions();
	setShouldResetSearchQuery(true);
	clearOnyxAndResetApp();
	};

clearOnyxAndResetApp already supports this case: after clearing Onyx, it navigates to ROUTES.HOME only when shouldNavigateToHomepage is true, then continues with the preserved session/account and openApp flow.

App/src/libs/actions/App.ts

Lines 881 to 923 in e4b4a90

	function clearOnyxAndResetApp(shouldNavigateToHomepage?: boolean) {
	// The value of isUsingImportedState will be lost once Onyx is cleared, so we need to store it
	const isStateImported = isUsingImportedState;
	rollbackOngoingRequest();
	const sequentialQueue = getAll();
	Navigation.clearPreloadedRoutes();
	// Seed LAST_FULL_RECONNECT_TIME so subscribeToFullReconnect doesn't fire a duplicate
	// ReconnectApp once the openApp() below lands NVP_RECONNECT_APP_IF_FULL_RECONNECT_BEFORE.
	const resetPromise = clearWorkboxRecoveryCaches().then(() =>
	clearOnyxAndSeedFullReconnect(KEYS_TO_PRESERVE)
	.then(() => {
	// Network key is preserved, so when exiting imported state, we should:
	// 1. Stop forcing offline mode so the app can reconnect
	// 2. Clear the IS_USING_IMPORTED_STATE flag
	// 3. Restore the original user session
	if (isStateImported) {
	setShouldForceOffline(false);
	Onyx.set(ONYXKEYS.IS_USING_IMPORTED_STATE, false);
	Log.info('[ImportedState] Exiting imported state mode, restoring original session');
	}
	if (shouldNavigateToHomepage) {
	Navigation.navigate(ROUTES.HOME);
	}
	if (preservedUserSession) {
	Onyx.set(ONYXKEYS.SESSION, preservedUserSession);
	Onyx.set(ONYXKEYS.PRESERVED_USER_SESSION, null);
	}
	if (preservedAccount) {
	Onyx.set(ONYXKEYS.ACCOUNT, preservedAccount);
	Onyx.set(ONYXKEYS.PRESERVED_ACCOUNT, null);
	}
	})
	.then(() => {
	// Requests in a sequential queue should be called even if the Onyx state is reset, so we do not lose any pending data.
	// However, the OpenApp request must be called before any other request in a queue to ensure data consistency.
	// To do that, sequential queue is cleared together with other keys, and then it's restored once the OpenApp request is resolved.
	// When exiting imported state, force openApp to run even though the variable might not be updated yet
	openApp(false, undefined, isStateImported).then(() => {
	if (!sequentialQueue || isStateImported) {

Because the troubleshoot flow never opts into that escape hatch, the reset can leave the app trying to continue from the volatile settings route while its supporting state has just been cleared, which is why the user can end up on the generic not-found page instead of a stable app screen.

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

Pass true when TroubleshootPage calls clearOnyxAndResetApp, matching the existing imported-state exit path. This makes "Reset and refresh" leave the troubleshoot route and restart from Home after clearing local state, instead of trying to keep rendering the page that initiated the reset.

App/src/components/ImportedStateIndicator.tsx

Lines 19 to 28 in e4b4a90

	return (
	<View style={[styles.buttonDanger]}>
	<Button
	danger
	small
	shouldRemoveLeftBorderRadius
	shouldRemoveRightBorderRadius
	text={translate('initialSettingsPage.troubleshoot.usingImportedState')}
	onPress={() => clearOnyxAndResetApp(true)}
	textStyles={[styles.fontWeightNormal]}

Test coverage:

• Add or update component coverage for TroubleshootPage so confirming the reset modal calls clearOnyxAndResetApp(true).
• Manually verify on web that Accounts > Troubleshoot > Clear cache and restart > Reset and refresh clears/reloads the app and lands on Home, not the "Hmm, it's not here" page.

What alternative solutions did you explore? (Optional)

We could add SCREENS.SETTINGS.TROUBLESHOOT to CONST.EXCLUDE_FROM_LAST_VISITED_PATH, but that only affects future last-visited-path persistence. The reset action itself should intentionally leave the route that is being cleared from under the app state.

[melvin-bot]

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