[$250] Add BA - Personal information RHP remains loading after reloading the page

[vincdargento]

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.38-1
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/test-runs/TR-9540/folder/13176691/41236744/1253292453?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: Web
App Component: Workspace Settings

Action Performed:

1. Go to Workspace -> Workflows -> Add bank account
2. Click on "Log into your bank account"
3. Click on the "Confirm" button
4. Complete the add bank account flow until the "Personal Information" step.
5. Go offline
6. Complete personal information steps and reach the confirmation page
7. Go online and refresh the page

Expected Result:

Personal Information confirm RHP should be displayed after reloading the page.

Actual Result:

"We’re taking a look at your information. You'll be able to continue with next steps shortly." RHP is displayed after reloading the page, also the back button is not functional.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @thelullabyy

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033697855301035920
• Upwork Job ID: 2033697855301035920
• Last Price Increase: 2026-03-24
• Automatic offers:
• thelullabyy | Contributor | 110938973

[MelvinBot]

Proposal

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

After completing the Personal Information steps while offline in the Add Bank Account flow (Workspace → Workflows → Add bank account), going online and refreshing the page shows a stuck "We're taking a look at your information" loading animation instead of the Personal Information confirmation RHP. The back button is also non-functional in this state.

What is the root cause of that problem?

The root cause is a stale isLoading: true state persisted in Onyx that never gets cleared after a page refresh.

Here's the sequence:

1. When the user submits from the Personal Info confirmation page offline, updatePersonalInformationForBankAccount (BankAccounts.ts:559-569) calls API.write with getVBBADataForOnyx(REQUESTOR, true).

2. getVBBADataForOnyx (BankAccounts.ts:178-217) immediately sets REIMBURSEMENT_ACCOUNT.isLoading = true in Onyx as optimistic data. The success/failure callbacks (which set isLoading: false) only fire when the server responds — but since the device is offline, the write request is queued and the callbacks never execute.

3. This isLoading: true is persisted to disk by Onyx. When the user goes online and refreshes, Onyx loads this stale state.

4. On page mount, the initial effect in ReimbursementAccountPage.tsx:237-255 checks isPreviousPolicy:

   if (isPreviousPolicy && !!reimbursementAccount) {
       return; // <-- Skips fetchData() entirely
   }

   Since the persisted achData.policyID matches the URL's policyIDParam, isPreviousPolicy is true, so fetchData() is never called to refresh the data from the server.

5. Meanwhile, hasLoadedData at line 196 evaluates to false because it requires !reimbursementAccount?.isLoading:

   const hasLoadedData = reimbursementAccount?.achData && !isDefaultReimbursementAccountData && !reimbursementAccount?.isLoading;

6. The loading indicator guard at lines 501-507 blocks the entire UI:

   if (
       (!!policyIDParam || !!bankAccountIDParam) &&
       (!hasACHDataBeenLoaded || isLoading || isLoadingWorkspaceReimbursement) &&
       shouldShowOfflineLoader &&
       (shouldReopenOnfido || !requestorStepRef?.current)
   ) {
       return <ReimbursementAccountLoadingIndicator onBackButtonPress={goBack} />;
   }

   All conditions are met: isLoading is true, hasACHDataBeenLoaded is false, shouldShowOfflineLoader is true (user is now online), and requestorStepRef.current is null (fresh mount). The loading animation renders indefinitely because no fetchData() was called to resolve the stale isLoading state.

The offline-to-online transition effect (line 292-297) also doesn't help after a refresh because prevIsOffline is undefined on the first render — there's no "previous" offline state to detect a transition from.

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

Modify the initial mount effect in ReimbursementAccountPage.tsx (lines 237-240) to still call fetchData() when isPreviousPolicy is true but isLoading is stuck as true:

useEffect(() => {
    if (isPreviousPolicy && !!reimbursementAccount) {
        // If isLoading is stale from a persisted offline state, fetch fresh data
        if (reimbursementAccount.isLoading) {
            fetchData();
        }
        return;
    }
    // ...rest of existing code unchanged
}, [isPreviousPolicy]);

This way, when the page mounts with a stale isLoading: true from a previous offline session, fetchData() is called to get fresh state from the server. The server response clears isLoading and restores the correct step. The existing isPreviousPolicy optimization is preserved for normal cases where data is already loaded.

What alternative solutions did you explore? (Optional)

1. Clear isLoading on mount when stale: Explicitly set isLoading: false in the mount effect when isPreviousPolicy is true and isLoading is true. However, this is less clean because it would flash the wrong step before the server response arrives.

2. Modify hasLoadedData to ignore isLoading when achData has real data: This would treat the data as "loaded" even with a pending write, but could mask other legitimate loading states.

3. Ensure clearReimbursementAccount() persists before page unload: The unmount cleanup at lines 153-160 calls clearReimbursementAccount() which resets to DEFAULT_DATA. However, on a hard browser refresh, Onyx persistence may not complete before the page unloads, making this unreliable.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

After completing the Personal Information sub-steps offline and refreshing the page while online, the user sees the "We're taking a look at your information" loading RHP instead of the Personal Information confirmation page. The back button also does not work in this state.

What is the root cause of that problem?

In PersonalInfo.tsx, the startFrom index for useSubStep is calculated as follows:

const isBankAccountVerifying = reimbursementAccount?.achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
const startFrom = useMemo(() => (isBankAccountVerifying ? 0 : getInitialSubStepForPersonalInfo(values)), [values, isBankAccountVerifying]);

When the bank account state is VERIFYING, startFrom is forced to 0 (the FullName sub-step) regardless of whether the user has already filled all fields. After the user completes the Personal Info sub-steps offline, the server already has state === VERIFYING from a prior sub-step submission. On page reload, the data from the server comes back with state === VERIFYING, so startFrom is set to 0 rather than 4 (the Confirmation sub-step). This means useSubStep initializes to the first sub-step, and the requestorStepRef — which is checked in the loading guard condition in ReimbursementAccountPage.tsx at line 505 (!requestorStepRef?.current) — remains unset because the rendered sub-step is not the outer PersonalInfo ref target. Combined with isLoading being true during the API round-trip, the page stays stuck rendering ReimbursementAccountLoadingIndicator.

The real intent of the isBankAccountVerifying guard was to restart the sub-steps from the beginning when the bank account is in a verifying state and the user hasn't yet submitted their personal information for review. But when all personal info values are already present, the user should land on the Confirmation sub-step.

App/src/pages/ReimbursementAccount/USD/Requestor/PersonalInfo/PersonalInfo.tsx

Lines 47 to 48 in cd4db13

	const isBankAccountVerifying = reimbursementAccount?.achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
	const startFrom = useMemo(() => (isBankAccountVerifying ? 0 : getInitialSubStepForPersonalInfo(values)), [values, isBankAccountVerifying]);

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

The fix is to change the startFrom logic so that isBankAccountVerifying only resets to sub-step 0 when there is actually missing personal info data. If all fields are filled, getInitialSubStepForPersonalInfo(values) already returns 4 (Confirmation), which is the correct starting point regardless of the bank account state.

App/src/pages/ReimbursementAccount/USD/Requestor/PersonalInfo/PersonalInfo.tsx

Lines 47 to 48 in cd4db13

	const isBankAccountVerifying = reimbursementAccount?.achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
	const startFrom = useMemo(() => (isBankAccountVerifying ? 0 : getInitialSubStepForPersonalInfo(values)), [values, isBankAccountVerifying]);

- const isBankAccountVerifying = reimbursementAccount?.achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
- const startFrom = useMemo(() => (isBankAccountVerifying ? 0 : getInitialSubStepForPersonalInfo(values)), [values, isBankAccountVerifying]);
+ const initialSubStep = useMemo(() => getInitialSubStepForPersonalInfo(values), [values]);
+ const isBankAccountVerifying = reimbursementAccount?.achData?.state === CONST.BANK_ACCOUNT.STATE.VERIFYING;
+ const startFrom = useMemo(
+     () => (isBankAccountVerifying && initialSubStep === 0 ? 0 : initialSubStep),
+     [isBankAccountVerifying, initialSubStep],
+ );

This preserves the original intent — if the bank account is verifying and there is no personal info data yet (meaning the user never filled the form), start from the beginning. But when the user has already filled all sub-steps, initialSubStep will be 4, and the Confirmation page will be shown correctly after a page reload. This also unblocks the requestorStepRef so the loading indicator resolves properly.

What alternative solutions did you explore? (Optional)

N/A

[yuvrajangadsingh]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-19 10:34:21 UTC.

Proposal (updated with deeper root cause fix)

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

After completing the Personal Information sub-steps offline and refreshing the page while online, the user is stuck on the "We're taking a look at your information" loading indicator forever. The back button is also non-functional.

What is the root cause of that problem?

There are two paths to this bug, both ending at the same stuck state:

Path 1 (stale persisted data): User submits Personal Info offline. updatePersonalInformationForBankAccount (line 559) calls getVBBADataForOnyx(REQUESTOR, true) which optimistically sets isLoading: true. The write is queued but callbacks never fire. On hard refresh, the cleanup effect at line 152-159 (clearReimbursementAccount()) uses async Onyx.set which doesn't persist before the browser kills the page. Stale isLoading: true remains.

Path 2 (mount-time race): On remount, when reimbursementAccount is undefined (still loading from IndexedDB), the effect at line 237-242 calls setReimbursementAccountLoading(true) BEFORE fetchData() can complete. fetchData() returns early at line 211 because isLoadingOnyxValue is true. So isLoading gets set to true but never cleared because the actual API call (openReimbursementAccountPage) never fires.

Both paths lead to the same stuck state: isLoading: true is stuck, hasLoadedData (line 195) is false (requires !isLoading), shouldShowOfflineLoader (line 472) doesn't bypass because isOffline is false, and all four conditions in the loading guard (lines 496-501) are met. Loading indicator renders indefinitely.

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

Fix the source: guard setReimbursementAccountLoading(true) at line 242 so it only runs when fetchData() can actually complete the API call.

In ReimbursementAccountPage.tsx, the effect at lines 237-242:

// Current (broken):
if (isPreviousPolicy && !!reimbursementAccount) {
    return;
}
setReimbursementAccountLoading(true);
fetchData();

The issue is setReimbursementAccountLoading(true) fires even when fetchData() will return early (because isLoadingOnyxValue at line 211). Fix by moving the loading state set inside fetchData() AFTER the early return guards, or by adding the same guard before setReimbursementAccountLoading:

if (isPreviousPolicy && !!reimbursementAccount) {
    return;
}
if (!isLoadingOnyxValue) {
    setReimbursementAccountLoading(true);
}
fetchData();

This way isLoading is only set to true when the API call will actually fire. If metadata is still loading, we skip setting isLoading and let fetchData() handle it on the next effect cycle when data is ready.

For Path 1 (stale persisted isLoading), add a safety check on mount: if isPreviousPolicy and reimbursementAccount?.isLoading is true but hasACHDataBeenLoaded is false, call fetchData(true) to clear the stale state with a fresh server fetch.

What alternative solutions did you explore? (Optional)

• Modifying shouldShowOfflineLoader to detect stale loading (my original approach): works as a bypass but leaves isLoading: true stuck in Onyx. Other code reading reimbursementAccount.isLoading could still behave incorrectly.
• MelvinBot's approach: similar root cause analysis but proposal was truncated.
• MobileMage's approach: fixes startFrom in PersonalInfo.tsx but that's downstream. The loading indicator blocks the render before PersonalInfo even mounts.

---

Update 2 (per @hungvu193's feedback): Previous cleanup effect guard caused flashing. Corrected approach:

The "Continue setup" button disappears after reload because OpenApp API fires while Onyx is still loading isLoadingApp from IndexedDB. OpenApp clears achData.state to empty, which makes hasInProgressUSDVBBA() return false (it requires achData.state to exist and not be OPEN/LOCKED).

Fix: Guard the OpenApp call with isLoadingOnyxValue on the isLoadingApp metadata. The component that triggers OpenApp on reload uses useOnyx(ONYXKEYS.IS_LOADING_APP) but doesn't check if the value has finished loading from storage. While Onyx is syncing, isLoadingApp is undefined, so the component proceeds as if the app needs to load and calls OpenApp, which wipes achData.state.

// Guard: don't call OpenApp while isLoadingApp is still loading from Onyx
const [isLoadingApp, isLoadingAppMetadata] = useOnyx(ONYXKEYS.IS_LOADING_APP);

// Add isLoadingOnyxValue check before triggering OpenApp
if (isLoadingOnyxValue(isLoadingAppMetadata)) {
    return;
}

This is the same pattern already used in fetchData() at line 211 (isLoadingOnyxValue(reimbursementAccountMetadata)) and in DeepLinkHandler.tsx (isLoadingOnyxValue(sessionMetadata)).

[mavrickdeveloper]

Proposal

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

After the user reaches the Personal Information part of the Add Bank Account flow, going back online and hard-refreshing does not reliably recover the in-progress Requestor setup through the same resume path that already works during a normal reconnect.

On the failing refresh branch, the page can stay behind the loading RHP instead of recovering the in-progress flow. Even when recovery succeeds, a refresh can clear the local reimbursement-account draft, so the app may return to the continuation entry point instead of rebuilding the exact Personal Information confirmation sub-step automatically.

What is the root cause of that problem?

This is a page-level recovery problem in ReimbursementAccountPage. The bad refresh behavior happens while the page is deciding whether and how to resume the in-progress flow.

ReimbursementAccountPage currently computes isPreviousPolicy as true while reimbursement-account metadata is still loading:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 128 to 130 in 2e5fcdc

	const contactMethodRoute = `${environmentURL}/${ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo)}`;
	const isPreviousPolicy =
	policyIDParam && !!reimbursementAccount && !isLoadingOnyxValue(reimbursementAccountMetadata) ? policyIDParam === achData?.policyID : isLoadingOnyxValue(reimbursementAccountMetadata);

fetchData() immediately returns when that metadata is still loading:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 211 to 214 in 2e5fcdc

	function fetchData(preserveCurrentStep = false) {
	if ((!policyIDParam && !bankAccountIDParam) || isLoadingOnyxValue(reimbursementAccountMetadata)) {
	return;
	}

The initial mount effect then makes its recovery decision off isPreviousPolicy, but it only reruns when isPreviousPolicy changes. If it executes while metadata is still loading, it can call fetchData(), hit the metadata-loading early return, and never revisit the same-policy mount recovery branch after the cached reimbursement-account data arrives. When same-policy reimbursement data is already present, that same effect also returns early instead of using the reconnect-style preserved resume fetch:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 237 to 255 in 2e5fcdc

	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}
	// If the step to open is empty, we want to clear the sub step, so the connect option view is shown to the user
	const isStepToOpenEmpty = getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency) === '';
	if (isStepToOpenEmpty) {
	setBankAccountSubStep(null);
	setPlaidEvent(null);
	}
	fetchData();
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isPreviousPolicy]); // Only re-run this effect when isPreviousPolicy changes, which happens once when the component first loads

By contrast, the working offline-to-online reconnect path explicitly calls fetchData(true), and fetchData(true) is the path that preserves the current step, sub-step, and draft:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 220 to 234 in 2e5fcdc

	// We can specify a step to navigate to by using route params when the component mounts.
	// We want to use the same stepToOpen variable when the network state changes because we can be redirected to a different step when the account refreshes.
	const stepToOpen = preserveCurrentStep ? currentStep : getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency);
	const subStep = isPreviousPolicy ? (achData?.subStep ?? '') : '';
	let localCurrentStep: ReimbursementAccountStep = '';
	if (preserveCurrentStep) {
	localCurrentStep = currentStep;
	} else if (isPreviousPolicy) {
	localCurrentStep = achData?.currentStep ?? '';
	}
	// When preserving the current step (e.g., coming back online), also preserve the draft
	// to prevent losing user selections made while offline
	openReimbursementAccountPage({stepToOpen, subStep, localCurrentStep, policyID: policyIDParam, shouldPreserveDraft: preserveCurrentStep});

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 292 to 297 in 2e5fcdc

	useEffect(
	() => {
	// Check for network change from offline to online
	if (prevIsOffline && !isOffline && prevReimbursementAccount && prevReimbursementAccount.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	fetchData(true);
	}

The page also clears the reimbursement-account draft on unmount, which explains why a hard refresh can lose the local Requestor draft even when the authoritative ACH step is still recoverable:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 153 to 160 in 2e5fcdc

	useEffect(() => {
	return () => {
	clearReimbursementAccountDraft();
	clearReimbursementAccount();
	getPaymentMethods(true);
	};
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, []);

So the actual root cause is a mount-time recovery gap in ReimbursementAccountPage:

• the refresh path can make its recovery decision before reimbursement-account metadata is ready
• the same-policy mount path does not reuse the existing reconnect-style fetchData(true) semantics for in-progress REQUESTOR recovery

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

We should make mount-time recovery use the same preserved resume semantics as the reconnect path, but only after reimbursement-account metadata is ready.

Changes:

1. Wait until reimbursement-account metadata is no longer loading before making the one-time mount recovery decision.
2. When reopening the same policy and the cached ACH state is the in-progress USD REQUESTOR step, call fetchData(true) on mount instead of returning early.
3. Keep the existing early return for other same-policy cases that do not need preserved Requestor recovery.
4. Ensure the mount-time recovery branch only runs once per mount.

Logic on why fetchData(true) specifically?:

• it preserves stepToOpen
• it preserves localCurrentStep
• it preserves subStep
• it sets shouldPreserveDraft: true

Those are the same resume semantics already used by the working reconnect path, so mount-time recovery should reuse that exact path for same-policy in-progress REQUESTOR recovery.

Code paths are all in:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 128 to 130 in 2e5fcdc

	const contactMethodRoute = `${environmentURL}/${ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo)}`;
	const isPreviousPolicy =
	policyIDParam && !!reimbursementAccount && !isLoadingOnyxValue(reimbursementAccountMetadata) ? policyIDParam === achData?.policyID : isLoadingOnyxValue(reimbursementAccountMetadata);

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 211 to 255 in 2e5fcdc

	function fetchData(preserveCurrentStep = false) {
	if ((!policyIDParam && !bankAccountIDParam) || isLoadingOnyxValue(reimbursementAccountMetadata)) {
	return;
	}
	if (bankAccountIDParam) {
	// we don't need to send the stepToOpen and subStep when opening by bankAccountID - the step is returned from the backend
	openReimbursementAccountPage({bankAccountID: Number(bankAccountIDParam)});
	return;
	}
	// We can specify a step to navigate to by using route params when the component mounts.
	// We want to use the same stepToOpen variable when the network state changes because we can be redirected to a different step when the account refreshes.
	const stepToOpen = preserveCurrentStep ? currentStep : getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency);
	const subStep = isPreviousPolicy ? (achData?.subStep ?? '') : '';
	let localCurrentStep: ReimbursementAccountStep = '';
	if (preserveCurrentStep) {
	localCurrentStep = currentStep;
	} else if (isPreviousPolicy) {
	localCurrentStep = achData?.currentStep ?? '';
	}
	// When preserving the current step (e.g., coming back online), also preserve the draft
	// to prevent losing user selections made while offline
	openReimbursementAccountPage({stepToOpen, subStep, localCurrentStep, policyID: policyIDParam, shouldPreserveDraft: preserveCurrentStep});
	}
	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}
	// If the step to open is empty, we want to clear the sub step, so the connect option view is shown to the user
	const isStepToOpenEmpty = getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency) === '';
	if (isStepToOpenEmpty) {
	setBankAccountSubStep(null);
	setPlaidEvent(null);
	}
	fetchData();
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isPreviousPolicy]); // Only re-run this effect when isPreviousPolicy changes, which happens once when the component first loads

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 292 to 297 in 2e5fcdc

	useEffect(
	() => {
	// Check for network change from offline to online
	if (prevIsOffline && !isOffline && prevReimbursementAccount && prevReimbursementAccount.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	fetchData(true);
	}

What outcome should we expect from this change?

After a hard refresh on the same policy while the USD bank-account setup is in the REQUESTOR step:

• the page should no longer remain stuck behind the loading RHP because of the skipped mount recovery branch
• the app should perform the preserved resume fetch through OpenReimbursementAccountPage
• the flow should recover to a valid continuation point instead of remaining trapped in the loading state

PS:

• if the hard refresh has already cleared reimbursementAccountDraft, this fix does not guarantee reconstruction of the exact Personal Information confirmation sub-step
• in that case, the app can still recover correctly to the continuation entry point while clearing the stuck loading state

Fix direction logic:

It fixes the actual refresh/reconnect mismatch at the page-recovery layer:

• the page should wait until reimbursement-account metadata is ready before making the one-time mount recovery decision
• once the cached same-policy REQUESTOR state is available, refresh should use the same preserved resume fetch that already works on reconnect
• that gives one coherent recovery model for the in-progress Requestor flow instead of allowing refresh to take a different mount-time path

What alternative solutions did you explore? (Optional)

--

[thelullabyy]

Proposal

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

"We’re taking a look at your information. You'll be able to continue with next steps shortly." RHP is displayed after reloading the page, also the back button is not functional.

What is the root cause of that problem?

1. Reloading the page causes reimbursementAccount to be undefined briefly while the data is being loaded from the IndexedDB. And this useEffect is triggered, which sets reimbursementAccount.isLoading to true via setReimbursementAccountLoading(true) call, and it calls fetchData() to fetch the reimbursementAccount

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 237 to 245 in 56ff757

	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}

2. But at the time fetchData is called, reimbursementAccount data is still loading, and fetchData function returns early here

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 211 to 223 in 56ff757

	function fetchData(preserveCurrentStep = false) {
	if ((!policyIDParam && !bankAccountIDParam) || isLoadingOnyxValue(reimbursementAccountMetadata)) {
	return;
	}
	if (bankAccountIDParam) {
	// we don't need to send the stepToOpen and subStep when opening by bankAccountID - the step is returned from the backend
	openReimbursementAccountPage({bankAccountID: Number(bankAccountIDParam)});
	return;
	}
	// We can specify a step to navigate to by using route params when the component mounts.
	// We want to use the same stepToOpen variable when the network state changes because we can be redirected to a different step when the account refreshes.
	const stepToOpen = preserveCurrentStep ? currentStep : getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency);
	const subStep = isPreviousPolicy ? (achData?.subStep ?? '') : '';

3. After the reimbursementAccount is loaded, isPreviousPolicy is still true, so this useEffect doesn't run again

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 237 to 245 in 56ff757

	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}

which causes reimbursementAccount.isLoading to be stuck at true value, and the page remains loading

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 501 to 507 in 56ff757

	if (
	(!!policyIDParam || !!bankAccountIDParam) &&
	(!hasACHDataBeenLoaded || isLoading || isLoadingWorkspaceReimbursement) &&
	shouldShowOfflineLoader &&
	(shouldReopenOnfido || !requestorStepRef?.current)
	) {
	return <ReimbursementAccountLoadingIndicator onBackButtonPress={goBack} />;

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

We should ensure that openReimbursementAccountPage is called along with setReimbursementAccountLoading to resolve the loading state. Since we skipped calling openReimbursementAccountPage when the reimbursementAccount is being loaded from the Onyx, we should also skip this useEffect with the same condition

if ((isPreviousPolicy && !!reimbursementAccount) || isLoadingOnyxValue(reimbursementAccountMetadata)) {
            return;
        }

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 237 to 245 in 56ff757

	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}

or skip calling setReimbursementAccountLoading when the reimbursementAccount data is loading

if (policyIDParam && !isLoadingOnyxValue(reimbursementAccountMetadata)) {
            setReimbursementAccountLoading(true);
            clearReimbursementAccountDraft();
        }

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 237 to 245 in 56ff757

	useEffect(() => {
	if (isPreviousPolicy && !!reimbursementAccount) {
	return;
	}
	if (policyIDParam) {
	setReimbursementAccountLoading(true);
	clearReimbursementAccountDraft();
	}

What alternative solutions did you explore? (Optional)

We can remove isLoadingOnyxValue(reimbursementAccountMetadata) condition here

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Lines 211 to 223 in 56ff757

	function fetchData(preserveCurrentStep = false) {
	if ((!policyIDParam && !bankAccountIDParam) || isLoadingOnyxValue(reimbursementAccountMetadata)) {
	return;
	}
	if (bankAccountIDParam) {
	// we don't need to send the stepToOpen and subStep when opening by bankAccountID - the step is returned from the backend
	openReimbursementAccountPage({bankAccountID: Number(bankAccountIDParam)});
	return;
	}
	// We can specify a step to navigate to by using route params when the component mounts.
	// We want to use the same stepToOpen variable when the network state changes because we can be redirected to a different step when the account refreshes.
	const stepToOpen = preserveCurrentStep ? currentStep : getStepToOpenFromRouteParams(route, hasConfirmedUSDCurrency);
	const subStep = isPreviousPolicy ? (achData?.subStep ?? '') : '';

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[chengyixu]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.