[$250] Expense - IOU is shown in preview & total is shown as loading,no expense details displayed

[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: V9.3.74
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-28774/folder/13176679/106914447/1413061850
Email or phone of affected tester (no customers): applausetester+s1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

Pre-condition
Payment currency set as USD for user A & B

1. Login new expensifail account - A

2. Login gmail account - user B

3. Launch app

4. As user B , send an IOU in USD

5. Open user A account

6. Turn to airoplane mode

7. Tap pay - pay with business account

8. Navigate to LHN & open workspace chat

9. Note IOU is shown in preview

10. Open the expense

11. Note total is shown as loading and no expense details displayed

Expected Result:

Expense report must be shown and expense details must be displayed.

Actual Result:

IOU is shown in preview & total is shown as loading,no expense details displayed in offline.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7153616_1778731669514.Screenrecorder-2026-05-14-09-35-58-822.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054952823579625885
• Upwork Job ID: 2054952823579625885
• Last Price Increase: 2026-05-21

[MelvinBot]

Proposal

What is the root cause of that problem?

When User A opens the expense after paying an IOU offline, MoneyRequestView.tsx:893 returns a skeleton view because it cannot resolve the transaction:

if ((!readonly && !transactionThreadReport?.reportID) || !transaction?.transactionID) {
    return <ReportActionsSkeletonView />;
}

The transaction is resolved through a chain at MoneyRequestView.tsx:195-200: parentReportActions → parentReportAction (via parentReportActionID) → IOUTransactionID → transaction. If the user never opened the IOU report directly before going offline, the IOU report's report actions (specifically the original CREATE action containing IOUTransactionID) and the transaction thread report were never fetched into Onyx.

The optimistic payment data in PayMoneyRequest.ts:262-303 only pushes updates for the chatReport, the iouReport, and the new PAY report action. It does not ensure the transaction thread report or the IOU report's original CREATE action (which holds the IOUTransactionID) are present in Onyx. So when the user navigates to the expense detail screen while offline, MoneyRequestView can't complete the lookup chain and falls back to the skeleton.

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

The optimistic data for the payment flow in PayMoneyRequest.ts should ensure the transaction thread report and the relevant parent report action (CREATE action with IOUTransactionID) are available in Onyx when the payment is made. Specifically, getPayMoneyRequestParams should include the transaction thread report and the IOU report's existing report actions in its optimistic data so that MoneyRequestView can resolve the full chain (transactionThreadReport → parentReportAction → IOUTransactionID → transaction) even when offline.

Alternatively, MoneyRequestView could be made more resilient by attempting to resolve the transaction directly from the derived report transactions (which are already available from the workspace chat's data) rather than exclusively relying on the parentReportAction → IOUTransactionID chain when the transaction thread report or parent report actions are not loaded.

What alternative solutions did you explore? (Optional)

Another approach would be to pre-fetch the IOU report's actions and transaction thread report when the user views the payment confirmation screen (before tapping "Pay"), ensuring the data is in Onyx before the offline payment occurs. However, this is less robust since the user could go offline between viewing and paying.

Investigation details

Data flow of the bug:

1. User B sends IOU to User A → workspace chat gets a REPORT_PREVIEW action linking to the IOU report. Transaction data is sent as part of OpenReport for the workspace chat.
2. User A views the workspace chat but never opens the IOU report directly → the IOU report's individual REPORT_ACTIONS (CREATE action) and the transaction thread report are not in Onyx.
3. User A goes offline and taps "Pay with business account" → optimistic data updates chatReport (sets iouReportID=null), adds PAY action to iouReport, updates iouReport status. Does not populate transaction thread report or the IOU report's original CREATE action.
4. User navigates to LHN → IOU preview visible in workspace chat (transaction data exists from step 1).
5. User opens the expense → MoneyRequestView tries to load transactionThreadReport (not in Onyx) and resolve transaction via parentReportActions (CREATE action not in Onyx). Both fail → skeleton view returned.

Key code locations:

• Skeleton gate: MoneyRequestView.tsx:893
• Transaction resolution chain: MoneyRequestView.tsx:195-200
• Optimistic payment data (missing transaction thread/CREATE action): PayMoneyRequest.ts:262-303
• chatReport.iouReportID set to null: PayMoneyRequest.ts:251
• Total loading spinner: MoneyReportView.tsx:241

---

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.

[mukhrr]

Proposal

What is the root cause of that problem?

When a user pays a personal IOU with a business bank account offline, BaseKYCWall.selectPaymentMethod triggers moveIOUReportToPolicy → convertIOUReportToExpenseReport to convert the IOU into an expense report on the policy expense chat before the actual payment fires.

The optimistic data in convertIOUReportToExpenseReport updates the old DM chat and the IOU report itself, but it never updates the new workspace expense chat with the iouReportID, lastVisibleActionCreated, lastMessageText/Html, or hasOutstandingChildRequest. The old DM has its iouReportID cleared (see src/libs/actions/Report/index.ts#L6962-L6970) but no corresponding write attaches the moved report to the new chat:

App/src/libs/actions/Report/index.ts

Lines 6909 to 6970 in 1b89b63

	// We need to move the report preview action from the DM to the expense chat.
	const oldChatReportID = iouReport.chatReportID;
	const reportPreviewActionID = iouReport.parentReportActionID;
	const reportPreview = !!oldChatReportID && !!reportPreviewActionID ? allReportActions?.[oldChatReportID]?.[reportPreviewActionID] : undefined;
	if (reportPreview?.reportActionID) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${oldChatReportID}`,
	value: {[reportPreview.reportActionID]: null},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${oldChatReportID}`,
	value: {[reportPreview.reportActionID]: reportPreview},
	});
	// Add the reportPreview action to expense chat
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${optimisticPolicyExpenseChatReportID}`,
	value: {[reportPreview.reportActionID]: {...reportPreview, childReportName: expenseReport.reportName, created: DateUtils.getDBTime()}},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${optimisticPolicyExpenseChatReportID}`,
	value: {[reportPreview.reportActionID]: null},
	});
	}
	// Create MOVED report action and add it to the expense report which indicates to the user where the report has been moved
	const movedExpenseReportAction = buildOptimisticMovedReportAction(iouReport.policyID, policyID, optimisticPolicyExpenseChatReportID, reportID, policy.name, true);
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {[movedExpenseReportAction.reportActionID]: movedExpenseReportAction},
	});
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[movedExpenseReportAction.reportActionID]: {
	...movedExpenseReportAction,
	pendingAction: null,
	},
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {[movedExpenseReportAction.reportActionID]: null},
	});
	// To optimistically remove the GBR from the DM we need to update the hasOutstandingChildRequest param to false
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${oldChatReportID}`,
	value: {
	hasOutstandingChildRequest: false,
	iouReportID: null,
	},
	});

After the move, payMoneyRequest runs against the (now-stale) workspace chat. Because that chat has no iouReportID and the previous step also issues iouReportID: null on whatever chatReport is passed in, the OfflineWithFeedback wrapper around the header keeps pendingFields.reimbursed: UPDATE indefinitely:

App/src/libs/actions/IOU/PayMoneyRequest.ts

Lines 247 to 297 in 1b89b63

	const optimisticChatReport = {
	...chatReport,
	lastReadTime: DateUtils.getDBTime(),
	hasOutstandingChildRequest: hasOutstandingChildRequest(chatReport, iouReport?.reportID, currentUserEmailParam, currentUserAccountIDParam, allTransactionViolations, undefined),
	iouReportID: null,
	lastMessageText: getReportActionText(optimisticIOUReportAction),
	lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
	};
	if (isIndividualInvoiceRoom(chatReport) && payAsBusiness && payerPolicyID) {
	optimisticChatReport.invoiceReceiver = {
	type: CONST.REPORT.INVOICE_RECEIVER_TYPE.BUSINESS,
	policyID: payerPolicyID,
	};
	}
	onyxData.optimisticData?.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${chatReport.reportID}`,
	value: optimisticChatReport,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
	value: {
	[optimisticIOUReportAction.reportActionID]: {
	...(optimisticIOUReportAction as OnyxTypes.ReportAction),
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
	value: {
	lastMessageText: getReportActionText(optimisticIOUReportAction),
	lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
	lastVisibleActionCreated: optimisticIOUReportAction.created,
	hasOutstandingChildRequest: false,
	statusNum: CONST.REPORT.STATUS_NUM.REIMBURSED,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	pendingFields: {
	preview: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	reimbursed: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	nextStep: optimisticNextStep,
	errors: null,
	},
	},

On Android (Hermes + Fabric), the report-actions/transactions collection selectors for MoneyRequestReportView resolve from the new chatReportID before the moved REPORT_PREVIEW action lands on the policy expense chat — so reportActions.length === 0, MoneyRequestReportView falls into the ReportActionsSkeletonView branch:

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 222 to 226 in 1b89b63

	}
	if (reportActions.length === 0) {
	return <ReportActionsSkeletonView shouldAnimate={false} />;
	}

That's the "no expense details" empty state, combined with the dimmed header OfflineWithFeedback produces — what looks like a "loading" total.

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

I'd extend convertIOUReportToExpenseReport so the new workspace expense chat is fully linked to the moved report in the same optimistic transaction. The minimum addition is a MERGE on ${REPORT}${optimisticPolicyExpenseChatReportID} that mirrors the data we strip from the old DM:

     // To optimistically remove the GBR from the DM we need to update the hasOutstandingChildRequest param to false
     optimisticData.push({
         onyxMethod: Onyx.METHOD.MERGE,
         key: `${ONYXKEYS.COLLECTION.REPORT}${oldChatReportID}`,
         value: {
             hasOutstandingChildRequest: false,
             iouReportID: null,
         },
     });
+    // Attach the moved report to the destination policy expense chat so MoneyRequestReportView
+    // can resolve actions/transactions via the new chatReportID immediately after navigation.
+    optimisticData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticPolicyExpenseChatReportID}`,
+        value: {
+            iouReportID: reportID,
+            hasOutstandingChildRequest: !isReportManuallyReimbursed(iouReport),
+            lastVisibleActionCreated: movedExpenseReportAction.created,
+            lastMessageText: getReportActionText(movedReportAction),
+            lastMessageHtml: getReportActionHtml(movedReportAction),
+        },
+    });
+    failureData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticPolicyExpenseChatReportID}`,
+        value: {iouReportID: null},
+    });

And in payMoneyRequest, only clear iouReportID on the chat when the report is not mid-move to a policy — otherwise the second optimistic write races the first and wipes the link we just established:

-    const optimisticChatReport = {
-        ...chatReport,
-        lastReadTime: DateUtils.getDBTime(),
-        hasOutstandingChildRequest: hasOutstandingChildRequest(chatReport, iouReport?.reportID, currentUserEmailParam, currentUserAccountIDParam, allTransactionViolations, undefined),
-        iouReportID: null,
-        lastMessageText: getReportActionText(optimisticIOUReportAction),
-        lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
-    };
+    const isMovedToPolicy = chatReport.reportID !== iouReport?.chatReportID;
+    const optimisticChatReport = {
+        ...chatReport,
+        lastReadTime: DateUtils.getDBTime(),
+        hasOutstandingChildRequest: hasOutstandingChildRequest(chatReport, iouReport?.reportID, currentUserEmailParam, currentUserAccountIDParam, allTransactionViolations, undefined),
+        // Keep the link when the IOU was just moved to this policy expense chat;
+        // otherwise the workspace chat loses its iouReportID immediately after the move.
+        iouReportID: isMovedToPolicy ? iouReport?.reportID : null,
+        lastMessageText: getReportActionText(optimisticIOUReportAction),
+        lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
+    };

The same MoneyRequestReportView skeleton fallback should also be hardened so that an empty reportActions list while offline doesn't render ReportActionsSkeletonView for a report we do have (report?.total present, transactions in Onyx) — guarding the early return at L224 with !isOffline makes the moved/paid expense visible immediately on Android too.

What alternative solutions did you explore? (Optional)

• Defer navigation with setNavigationActionToMicrotaskQueue — already done in PR Fix wrong next action message, missing Pay button after bypassing approver & approving offline #72892 for a sibling bug; it improves timing but doesn't fix the missing optimistic link, so the symptom returns the next time the user navigates back into the report.
• Skip the IOU→policy move entirely when offline and just run payMoneyRequest. Rejected: it diverges the offline/online flows and the BE expects the move to have happened before settlement when paying as business.

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

buildOptimisticTaskCommentReportAction retroactively stamps actorAccountID onto the report action after the body has been built — but the body's person array and avatar field were already baked from the current user, not the guide. The patch-up at the end overwrites only one of the three fields that identify the actor:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L6459

const reportAction = buildOptimisticAddCommentReportAction({text, reportID: taskReportID, ...});
// ^ actorAccountID is not threaded into the nested builder

Inside that nested builder, with no actorAccountID argument, accountID falls through to the current user:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L6325

const accountID = actorAccountID ?? currentUserAccountID ?? deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID;

And accountID is what drives the actor's display name and avatar:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L6336-L6345

actorAccountID: accountID,
person: [{style: 'strong', text: allPersonalDetails?.[accountID]?.displayName ?? currentUserEmail ?? deprecatedCurrentUserEmail, type: 'TEXT'}],
automatic: false,
avatar: allPersonalDetails?.[accountID]?.avatar,

After the builder returns, the outer function does:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L6485-L6487

if (actorAccountID) {
    reportAction.reportAction.actorAccountID = actorAccountID;
}

Only actorAccountID is fixed. person[0].text and avatar still point at the freshly-signed-up user — whose displayName falls back to their login (their email) and whose avatar is the default-generated fallback URL since they haven't uploaded one yet. That's exactly the symptom in the bug report: the actor renders as user@tstsg.com with a fallback avatar instead of qa.guide@team.expensify.com with the guide's avatar.

The setup specialist's personal details do exist on the device by this point — prepareOnboardingOnyxData Onyx.merges them at https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L11703-L11711 — but the renderer reads person/avatar straight off the report action, so a wrong identity baked at build time wins.

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

Thread actorAccountID into the nested builder so the person/avatar fields are computed from the guide's account from the start. The retroactive patch then becomes redundant.

- function buildOptimisticTaskCommentReportAction(
-     taskReportID: string,
-     taskTitle: string,
-     taskAssigneeAccountID: number,
-     text: string,
-     parentReportID: string | undefined,
-     actorAccountID?: number,
-     createdOffset = 0,
-     currentUserEmail?: string,
-     currentUserAccountID?: number,
- ): OptimisticReportAction {
-     const reportAction = buildOptimisticAddCommentReportAction({
-         text,
-         reportID: taskReportID,
-         createdOffset,
-         currentUserEmail,
-         currentUserAccountID,
-         delegateAccountIDParam: undefined,
-     });
+ function buildOptimisticTaskCommentReportAction(
+     taskReportID: string,
+     taskTitle: string,
+     taskAssigneeAccountID: number,
+     text: string,
+     parentReportID: string | undefined,
+     actorAccountID?: number,
+     createdOffset = 0,
+     currentUserEmail?: string,
+     currentUserAccountID?: number,
+ ): OptimisticReportAction {
+     const reportAction = buildOptimisticAddCommentReportAction({
+         text,
+         reportID: taskReportID,
+         createdOffset,
+         currentUserEmail,
+         currentUserAccountID,
+         actorAccountID,
+         delegateAccountIDParam: undefined,
+     });
      ...
-     if (actorAccountID) {
-         reportAction.reportAction.actorAccountID = actorAccountID;
-     }
+     // actorAccountID is now applied inside buildOptimisticAddCommentReportAction, so person/avatar
+     // are built from the guide's personal details instead of the current user's.
      return reportAction;
  }

buildOptimisticAddCommentReportAction already accepts actorAccountID in its BuildOptimisticAddCommentReportActionParams and uses it at L6325 — we just have to stop dropping it on the way through. With this change:

• accountID resolves to the guide account
• person[0].text reads allPersonalDetails[guideAccountID].displayName → the merge at L11703-L11711 wrote displayName: assignedGuideEmail for this exact account, so for the bug's scenario it renders as qa.guide@team.expensify.com (or "Setup Specialist" while the assigned-guide email is still pending from the backend, but never the user's email)
• avatar reads allPersonalDetails[guideAccountID].avatar → the guide's actual avatar once the personal-details fetch resolves; until then, the same fallback the merge wrote — never the current user's avatar

The if (actorAccountID) { actorAccountID = ... } patch at L6485-L6487 becomes a no-op (the value is already set inside the builder) and can be removed.

I'd also follow the existing module-level allPersonalDetails cache: at the moment prepareOnboardingOnyxData runs, Onyx.merge at L11703 is async and the module cache reflects the merge on the next tick. Since these optimistic actions don't ship to the UI until the API call's optimisticData is applied (which happens after the function returns), the merge will have landed by render time — so the lookup at L6340/L6345 will find the guide's row, not miss it.

What alternative solutions did you explore?

I considered extending the retroactive patch at L6485-L6487 to also rebuild person and avatar. That works but duplicates the exact computation already present at L6340/L6345, and creates two places to update if those fields ever change shape. Pushing actorAccountID through the constructor keeps the rule "actor is what accountID decides" in one location.

I considered leaving buildOptimisticTaskCommentReportAction alone and instead populating person/avatar at the onboarding call site (L11840) with values pulled from allPersonalDetails[assignedGuideAccountID]. That fixes this caller specifically but leaves the helper subtly broken for every other caller that passes a non-current-user actorAccountID — the bug would re-surface anywhere else the same mistake is repeated.

[melvin-bot]

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

[github-actions]

⚠️ @dilshodmackbook-sketch Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[github-actions]

⚠️ @dilshodmackbook-sketch Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[aswin-s]

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

When User A pays an IOU offline without having previously opened the IOU report, the expense detail view shows a loading skeleton instead of the transaction details. User A can see the IOU in the workspace chat preview, but opening the expense displays only a loading state with no expense details visible. The expected behavior is to display the full expense report and transaction details even when the underlying transaction thread report or parent CREATE action was never fetched online.

What is the root cause of that problem?

The root cause is in src/libs/actions/IOU/PayMoneyRequest.ts:247–303 in the getPayMoneyRequestParams function. When processing an offline payment, the function pushes optimistic updates for the chatReport, iouReport, PAY action, and report preview, but it never ensures that the transaction thread report or the IOU report's original CREATE action (which contains IOUTransactionID) are present in Onyx. If User A never opened the IOU report directly before going offline, those records were never fetched from the server.

When MoneyRequestView mounts (lines 195–200), it attempts to resolve parentReportActions[transactionThreadReport.parentReportActionID] to find the linked transaction. Since the parent CREATE action is missing from Onyx, linkedTransactionID and transaction remain undefined. This triggers the gate at line 893:

if ((!readonly && !transactionThreadReport?.reportID) || !transaction?.transactionID) return <ReportActionsSkeletonView />;

This is the 'total is loading, no details' symptom reported. The issue is consistently reproducible on Android (the platform in the bug report) because Android does not prefetch report action threads during LHN rendering — iOS may prefetch them in some app states, which is why the bug is platform-specific in practice even though the root cause is platform-agnostic.

Working analog (same file, successful pattern):

App/src/libs/actions/IOU/PayMoneyRequest.ts

Lines 290 to 298 in 7152d98

	reimbursed: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	nextStep: optimisticNextStep,
	errors: null,
	},
	},
	{

The code already conditionally pushes a MERGE for the report preview action when it exists locally — the same pattern should apply to the transaction thread report and parent CREATE action.

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

1. File: src/libs/actions/IOU/PayMoneyRequest.ts
   Function: getPayMoneyRequestParams
   Description: After the existing optimistic updates, conditionally push two additional MERGE operations: (a) the IOU report's CREATE action into REPORT_ACTIONS[iouReportID] when the parent CREATE action with IOUTransactionID is not already in Onyx, and (b) the transaction thread report into REPORT[transactionThreadReportID] when missing. This ensures MoneyRequestView's parentReportActions → parentReportAction → IOUTransactionID → transaction chain resolves even when the user never opened the IOU report online.

   Exact code to add (after line 303, before the return statement):

   // Ensure the transaction thread report and parent CREATE action are present in Onyx so the
   // expense detail view can resolve transaction details when opened offline (e.g. directly after
   // an offline pay). Without this, MoneyRequestView falls back to ReportActionsSkeletonView.
   const iouCreateAction = getIOUActionForReportID(iouReport?.reportID, undefined);
   const transactionThreadReportID = iouCreateAction?.childReportID;
   
   // Guard: only proceed if both values are non-null strings — an absent or malformed
   // iouCreateAction means the IOU has no CREATE action in local Onyx, in which case
   // we cannot construct a valid MERGE payload and must skip to avoid writing partial state.
   if (
       iouCreateAction &&
       typeof iouCreateAction.reportActionID === 'string' &&
       iouCreateAction.reportActionID.length > 0 &&
       typeof transactionThreadReportID === 'string' &&
       transactionThreadReportID.length > 0
   ) {
       // Only merge the CREATE action if it is not already present in Onyx to avoid
       // overwriting a more-complete server-fetched version with a stale local copy.
       const existingCreateAction = allReportActions?.[iouReport?.reportID ?? '']?.[iouCreateAction.reportActionID];
       if (!existingCreateAction) {
           onyxData.optimisticData?.push({
               onyxMethod: Onyx.METHOD.MERGE,
               key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
               value: {
                   [iouCreateAction.reportActionID]: iouCreateAction,
               },
           });
       }
   
       // Only merge the thread report stub if it is not already present in Onyx.
       const existingThreadReport = allReports?.[transactionThreadReportID];
       if (!existingThreadReport?.reportID) {
           onyxData.optimisticData?.push({
               onyxMethod: Onyx.METHOD.MERGE,
               key: `${ONYXKEYS.COLLECTION.REPORT}${transactionThreadReportID}`,
               value: {
                   reportID: transactionThreadReportID,
                   parentReportID: iouReport?.reportID,
                   parentReportActionID: iouCreateAction.reportActionID,
               },
           });
       }
   }

   The existing Onyx state checks (existingCreateAction and existingThreadReport?.reportID) ensure we never overwrite a server-fetched record with a stale optimistic stub. The string-length guards on reportActionID and transactionThreadReportID prevent writing keys like REPORT_ACTIONS_ or REPORT_ to Onyx if either value is unexpectedly empty.

Blast radius: The change is scoped to optimistic data initialization in the offline payment flow. It only adds missing Onyx records that should already exist, ensuring the expense detail view's dependency chain resolves without altering payment logic or report state transitions.

What alternative solutions did you explore? (Optional)

N/A