[Due for payment 2026-08-08] [$250] Web - Invoice - Skeleton loading until refresh page on first time created invoice to the user

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-32728/folder/13176671/41237461/1434928218
Email or phone of affected tester (no customers): lekima20+623105@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com
2. At Inbox tab, click on FAB > Send Invoice
3. Complete sending invoice to a user who has never received an invoice before
4. Wait few seconds

Expected Result:

Invoice room is created without error

Actual Result:

Sending invoice to user who has never received an invoice before, Invoice room displays then skeleton loading infinitely until refresh page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7161549_1779564125621.Recording__2152.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7161549

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058762163166899438
• Upwork Job ID: 2058762163166899438
• Last Price Increase: 2026-06-29

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/14267abc4d4fa0af099770334e0518e3d306975af4af2087d4c8140d06a5e3ce

[MelvinBot]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 06:33:23 UTC.

Proposal

What is the root cause of that problem?

When sending an invoice to a first-time recipient, sendInvoice() sets isOptimisticReport: true on the new invoice chat room's metadata (SendInvoice.ts:249-257). When the user navigates to this room, ReportFetchHandler.fetchReport sees isOptimisticReport=true + type=CHAT + !isPolicyExpenseChat and skips calling openReport.

Later, when the SendInvoice API succeeds, isOptimisticReport is set back to false — but the effect that calls fetchReport has [route, isLinkedMessagePageReady, reportActionIDFromRoute] as its dependency array, which does not include isOptimisticReport. So fetchReport is never re-triggered, and openReport is never called.

Because openReport is the only writer of RAM_ONLY_REPORT_LOADING_STATE for that room, the loading-state record is never written and useOnyx falls back to the default {isLoadingInitialReportActions: true, hasOnceLoadedReportActions: false}. That permanently keeps isUnreadMessagePageLoadingInitially true (the room is briefly considered unread once the server bumps lastVisibleActionCreated past the optimistic lastReadTime, and hasOnceLoadedReportActions is falsy), so isReportReady stays false and the skeleton renders forever.

Refreshing fixes it because RAM-only state is cleared, isOptimisticReport is now false (report exists on server), and openReport succeeds normally.

The regular money-request flow does not have this bug because buildOnyxDataForMoneyRequest already seeds the loading-state record for the freshly-created report in its optimistic data (MoneyRequestBuilder.ts:657-663). SendInvoice is simply missing the equivalent write.

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

In buildOnyxDataForInvoice in SendInvoice.ts, inside the existing if (chat.isNewReport) block (right next to the isOptimisticReport: true push), add an optimistic-data write that seeds RAM_ONLY_REPORT_LOADING_STATE for the new invoice chat room keyed on chat.report.reportID, mirroring exactly what MoneyRequestBuilder.ts:657-663 does for newly-created money-request reports:

         if (chat.isNewReport) {
             optimisticData.push({
                 onyxMethod: Onyx.METHOD.MERGE,
                 key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${chat.report?.reportID}`,
                 value: {
                     isOptimisticReport: true,
                 },
             });
+            optimisticData.push({
+                onyxMethod: Onyx.METHOD.MERGE,
+                key: `${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${chat.report?.reportID}`,
+                value: {
+                    hasOnceLoadedReportActions: true,
+                },
+            });
         }

This is the same optimistic-data pattern the money-request flow already uses: sendInvoice builds the room's CREATED + REPORTPREVIEW actions locally, so the actions are genuinely "loaded" the moment we navigate — seeding hasOnceLoadedReportActions: true flips the !hasOnceLoadedReportActions term in isUnreadMessagePageLoadingInitially to false and the skeleton resolves immediately, with no extra network round-trip. No successData/failureData change is needed — the loading-state record stays valid in both outcomes, and we never want to re-show the skeleton over our own optimistic content.

Supporting type change: add | typeof ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE to the optimisticData OnyxUpdate<...> key union (around SendInvoice.ts:225-233) so TypeScript accepts the new entry — exactly as MoneyRequestBuilder.ts declares it in its key union.

What alternative solutions did you explore? (Optional)

1. Add reportMetadata.isOptimisticReport to the fetchReport effect's dependency array so that when it flips to false, fetchReport re-runs and calls openReport. This issues an unnecessary openReport API call for a report whose data is already available from the SendInvoice response, adding latency and server load, and flashes a skeleton until it resolves. Rejected in favor of seeding the loading state directly.
2. Relax the isOptimisticReport guard in ReportFetchHandler to allow openReport for invoice rooms. Same redundant fetch as (1), and weakening the guard for one chat sub-type is more fragile than the source-level seed.

Related issues

• Expensify/App#87032 — Similar skeleton loading symptoms for expenses (may share the same hasOnceLoadedReportActions root cause pattern)

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/91557#issuecomment-4531399079) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When sending an invoice to a user who has never received one before, the newly created invoice room displays a skeleton loading indicator that never resolves until the page is manually refreshed. This only affects web and only occurs when a brand-new invoice chat room is being created (first-time recipient).

What is the root cause of that problem?

The skeleton in ReportActionsList is driven by shouldWaitForTransactions in MoneyRequestReportUtils.ts. That function returns true (keep showing skeleton) when the report is an invoice report, has zero transactions so far, and isStillLoadingData is true. isStillLoadingData is true when reportLoadingState?.isLoadingInitialReportActions is truthy AND hasOnceLoadedReportActions is false. There is one escape hatch that bypasses the skeleton even in that case: report?.pendingFields?.createReport === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD (line 150 of MoneyRequestReportUtils.ts) — the intent is that a freshly-created optimistic report should not show a skeleton while it waits for the server.

The bug is that buildOnyxDataForInvoice in SendInvoice.ts sets the IOU invoice report's pending field as createChat (line 159), not createReport. Because the key name doesn't match what shouldWaitForTransactions checks (createReport), the escape hatch never fires. At the same time, RAM_ONLY_REPORT_LOADING_STATE for the new invoice room is never written by SendInvoice.ts, so useOnyx returns the declared default of { isLoadingInitialReportActions: true, hasOnceLoadedReportActions: false }. The combination means isStillLoadingData is permanently true on first load, shouldWaitForTransactions returns true, and ReportActionsList renders <ReportActionsSkeletonView /> forever until a page refresh (which triggers openReport and properly sets isLoadingInitialReportActions: false).

App/src/libs/MoneyRequestReportUtils.ts

Lines 143 to 151 in de3e3bf

	const isStillLoadingData =
	transactions?.length === 0 &&
	((!!reportLoadingState?.isLoadingInitialReportActions && !reportLoadingState.hasOnceLoadedReportActions) || report?.total !== 0 || hasPendingDismissWrite);
	return (
	(isMoneyRequestReport(report) || isInvoiceReport(report)) &&
	(!isTransactionDataReady || isStillLoadingData) &&
	!isTransactionThreadView &&
	report?.pendingFields?.createReport !== CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD
	);

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

In buildOnyxDataForInvoice inside src/libs/actions/IOU/SendInvoice.ts, change the optimistic pending field key for the IOU invoice report from createChat to createReport. The IOU report object at line 153–162 sets pendingFields: { createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD }. Renaming that key to createReport makes it consistent with the guard in shouldWaitForTransactions, so the skeleton is bypassed for a newly created optimistic invoice report exactly as intended.

The corresponding successData and failureData entries that clear this pending field (around lines 306–315 and 437–444) also use createChat on the IOU report and should be renamed to createReport in the same pass so the cleanup paths stay consistent.

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

Lines 153 to 162 in de3e3bf

	key: `${ONYXKEYS.COLLECTION.REPORT}${iou.report?.reportID}`,
	value: {
	...iou.report,
	lastMessageText: getReportActionText(iou.action),
	lastMessageHtml: getReportActionHtml(iou.action),
	pendingFields: {
	createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	},

What alternative solutions did you explore? (Optional)

An alternative would be to add RAM_ONLY_REPORT_LOADING_STATE optimistic/success entries directly into buildOnyxDataForInvoice (mirroring what openReport does), setting isLoadingInitialReportActions: true optimistically and false in success/failure data. This would also unblock the skeleton but it is a larger change and adds RAM_ONLY_REPORT_LOADING_STATE writes to a flow that currently does not need them. The pending field rename is more targeted and directly addresses the mismatch with the existing guard.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 04:18:33 UTC.

Proposal

What is the root cause of that problem?

SEND_INVOICE fails server-side for many invocations (I verified on staging that the backend rejects with jsonCode: 666 "Company website is invalid" for realrecipient.example.com, while expensify.com succeeded). When it fails, buildOnyxDataForInvoice's failureData correctly writes errorFields.createChat on the optimistic invoice chat room: src/libs/actions/IOU/SendInvoice.ts#L424-L437.

But ReportScreen's useOnyx selector that feeds OfflineWithFeedback only reads errorFields.createReport — not errorFields.createChat: src/pages/inbox/ReportScreen.tsx#L89-L94. So the failure is written to Onyx but never surfaces in the UI.

Meanwhile the room is still optimistic (isOptimisticReport: true) and RAM_ONLY_REPORT_LOADING_STATE is never seeded (ReportFetchHandler skips openReport for optimistic CHAT rooms), so the isUnreadMessagePageLoadingInitially gate fires here (src/pages/inbox/report/ReportActionsView.tsx#L218) and ReportActionsSkeletonView renders. Net effect: infinite skeleton with no error indicator, and a cache clear wipes the room because it's only in optimistic local Onyx.

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

Let the server stay the source of truth for what's a valid invoice (website, recipient, etc.) and just make sure its existing failure response actually reaches the user. Update the selector in ReportScreen to also recognize the field name that SendInvoice uses (createChat):

  reportPendingAction:
-     r?.pendingFields?.createReport ?? r?.pendingFields?.reportName,
+     r?.pendingFields?.createChat ?? r?.pendingFields?.createReport ?? r?.pendingFields?.reportName,
  reportErrors:
-     r?.errorFields?.createReport,
+     r?.errorFields?.createChat ?? r?.errorFields?.createReport,

With that change, OfflineWithFeedback's red error row + Dismiss (X) button render on the room, the user sees the failure, clicking Dismiss runs the existing dismissReportCreationError → removeFailedReport flow and the optimistic room is rolled back. I verified this end-to-end on local dev: error row appears, Dismiss bounces the user back, room is removed from Onyx. I also confirmed the success path (valid website + real recipient) is untouched.

What alternative solutions did you explore? (Optional)

• Add server side validation on checking valid websites.
• Seed RAM_ONLY_REPORT_LOADING_STATE in buildOnyxDataForInvoice (my earlier proposal).

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

Web - Invoice - Skeleton loading until refresh page on first time created invoice to the user

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.