[Due for payment 2025-11-12] [$250] Expense - Report view turns to skeleton loader after paying IOU expense via workspace offline

[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.2.29-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/test-runs/TR-1235/folder/13177049/41237817/945415338
Email or phone of affected tester (no customers): applausetester+101001kh@applause.expensifail.com
Issue reported by: Applause - Internal Team

Action Performed:

Precondition:

• User A default currency is USD
• User B has a workspace

1. Go to staging.new.expensify.com
2. [User A] Submit an IOU expense to User B
3. [User B] Open the IOU report
4. [User B] Go offline
5. {User B] Click Pay > Pay via workspace
6. [User B] Close the RHP

Expected Result:

Report view will not turn to skeleton loader

Actual Result:

Report view turns to skeleton loader after paying IOU expense via workspace offline

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
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6972348_1760215823398.offline.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021978695300058866413
• Upwork Job ID: 1978695300058866413
• Last Price Increase: 2025-10-23

Issue Owner

Current Issue Owner: @deetergp

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[mukhrr]

Proposal

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

When User B pays an IOU expense via workspace while offline and then closes the payment RHP, the report view incorrectly displays a skeleton loader instead of showing the optimistic payment data

What is the root cause of that problem?

We are missing offline check in the skeleton loader condition at MoneyRequestReportView.tsx:

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 182 to 202 in f05f7b7

	if (isLoadingApp) {
	return (
	<View style={styles.flex1}>
	<HeaderGap />
	<ReportHeaderSkeletonView />
	<ReportActionsSkeletonView />
	{shouldDisplayReportFooter ? (
	<ReportFooter
	report={report}
	reportMetadata={reportMetadata}
	policy={policy}
	pendingAction={reportPendingAction}
	isComposerFullSize={!!isComposerFullSize}
	lastReportAction={lastReportAction}
	// If the report is from the 'Send Money' flow, we add the comment to the `iou` report because for these we don't combine reportActions even if there is a single transaction (they always have a single transaction)
	transactionThreadReportID={isSentMoneyReport ? undefined : transactionThreadReportID}
	/>
	) : null}
	</View>
	);
	}

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

We should check again isOffline too.

if (isLoadingApp && !isOffline) {
  // existing skeleton loading logic
}

We already do the same in codebase

App/src/pages/home/report/ReportActionsView.tsx

Lines 297 to 302 in f05f7b7

	// Show skeleton while the app is loading and we're online
	const shouldShowSkeletonForAppLoad = isLoadingApp && !isOffline;
	if (shouldShowSkeletonForInitialLoad ?? shouldShowSkeletonForAppLoad) {
	return <ReportActionsSkeletonView />;
	}

App/src/pages/workspace/WorkspacesListPage.tsx

Line 116 in f05f7b7

const shouldShowLoadingIndicator = isLoadingApp && !isOffline;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

[Tony-MK]

Proposal

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

Report view turns to skeleton loader after paying IOU expense via workspace offline

What is the root cause of that problem?

In MoneyRequestReportView, the app shows the skeleton view instead of the MoneyRequestReportActionsList because it is loading, and the condition is met.

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 186 to 187 in d41575d

	if (isLoadingApp) {
	return (

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

We should change the condition to check if the report's pending action is not available.

if (isLoadingApp && !reportPendingAction) {
    return (

Screen.Recording.2025-10-12.at.22.11.09.mov

[paulnjs]

Proposal

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

• Expense - Report view turns to skeleton loader after paying IOU expense via workspace offline

What is the root cause of that problem?

• When User B selects Pay > Pay via workspace, the following logic is triggered:

App/src/components/KYCWall/BaseKYCWall.tsx

Lines 124 to 127 in f05f7b7

	const inviteResult = moveIOUReportToPolicyAndInviteSubmitter(iouReport?.reportID, adminPolicy, formatPhoneNumber);
	if (inviteResult?.policyExpenseChatReportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(inviteResult.policyExpenseChatReportID));
	} else {

• This calls:

App/src/libs/actions/Report.ts

Line 5389 in f05f7b7

function moveIOUReportToPolicyAndInviteSubmitter(

• Inside this function, we optimistically create a policy expense chat report:

App/src/libs/actions/Report.ts

Line 5439 in f05f7b7

const policyExpenseChats = createPolicyExpenseChats(policyID, invitedEmailsToAccountIDs);

• This is the same report we try to open immediately after:

App/src/components/KYCWall/BaseKYCWall.tsx

Line 126 in f05f7b7

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(inviteResult.policyExpenseChatReportID));

• However, the navigation occurs too soon—before the optimistic report is fully merged into Onyx. This causes the subsequent navigation call to fetch a partially built report with only {reportName: Chat Report}:

App/src/libs/actions/Report.ts

Line 1056 in f05f7b7

const optimisticReport = reportActionsExist(reportID)

• As a result, the app navigates to a report that lacks complete data, which leads to an infinite loading skeleton.

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

• We need to ensure that Onyx has successfully merged the optimistic report data before navigating to it.
• This can be achieved by deferring the navigation using the setNavigationActionToMicrotaskQueue utility, which waits until the next microtask before executing the navigation. Example:

App/src/components/KYCWall/BaseKYCWall.tsx

Lines 125 to 139 in f05f7b7

	if (inviteResult?.policyExpenseChatReportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(inviteResult.policyExpenseChatReportID));
	} else {
	const moveResult = moveIOUReportToPolicy(iouReport?.reportID, adminPolicy, true);
	savePreferredPaymentMethod(iouReport.policyID, adminPolicy.id, CONST.LAST_PAYMENT_METHOD.IOU, lastPaymentMethod?.[adminPolicy.id]);
	if (moveResult?.policyExpenseChatReportID && !moveResult.useTemporaryOptimisticExpenseChatReportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(moveResult.policyExpenseChatReportID));
	}
	}
	if (adminPolicy?.achAccount) {
	return;
	}
	Navigation.navigate(ROUTES.BANK_ACCOUNT_WITH_STEP_TO_OPEN.getRoute(adminPolicy.id));
	return;

if (inviteResult?.policyExpenseChatReportID) {
    setNavigationActionToMicrotaskQueue(() => {
        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(inviteResult.policyExpenseChatReportID));
        if (adminPolicy?.achAccount) {
            return;
        }
        Navigation.navigate(ROUTES.BANK_ACCOUNT_WITH_STEP_TO_OPEN.getRoute(adminPolicy.id));
    });
} else {
    const moveResult = moveIOUReportToPolicy(iouReport?.reportID, adminPolicy, true);
    savePreferredPaymentMethod(iouReport.policyID, adminPolicy.id, CONST.LAST_PAYMENT_METHOD.IOU, lastPaymentMethod?.[adminPolicy.id]);

    if (moveResult?.policyExpenseChatReportID && !moveResult.useTemporaryOptimisticExpenseChatReportID) {
        setNavigationActionToMicrotaskQueue(() => {
            Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(moveResult.policyExpenseChatReportID));
            if (adminPolicy?.achAccount) {
                return;
            }
            Navigation.navigate(ROUTES.BANK_ACCOUNT_WITH_STEP_TO_OPEN.getRoute(adminPolicy.id));
        });
    }
}

• We should apply this pattern in other similar areas where premature navigation could lead to broken or partial views—especially when dealing with optimistic data.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

None

[melvin-bot]

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

[melvin-bot]

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