[Due for payment 2026-04-30] [$250] Expense - App crashes after invited member leaves IOU report

[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.3.58-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-17824/folder/13177075/41237842/1320796345?sort=-identifier
Email or phone of affected tester (no customers): sdiosjnodjsodisjo2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. [User A] Submit two IOU expenses to User B.
3. [User A] Open the IOU report.
4. [User A] Mention User C and send the mention in the report.
5. [User A] Click Invite to chat only.
6. [User C] Open the invited report.
7. [User C] Click on the report header > Leave.

Expected Result:

App will not crash after invited member leaves IOU report.

Actual Result:

App crashes after invited member leaves IOU report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7126935_1775839844599.11.mp4

Bug7126935_1775839844596!staging.new.expensify.com-1775839675543.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @DylanDylann

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042672340170102057
• Upwork Job ID: 2042672340170102057
• Last Price Increase: 2026-04-10
• Automatic offers:
• FitseTLT | Reviewer | 111131024

[MelvinBot]

Proposal

What is the root cause of that problem?

When an invited member (User C) leaves an IOU report, leaveRoom (Report/index.ts:4420-4438) optimistically merges reportID: null into the report. The report object still exists in Onyx (it's truthy), but its reportID field is now null.

ReportActionsList (ReportActionsList.tsx:48-53) guards with !report (which passes since the object is truthy) and then passes report.reportID (null) to MoneyRequestReportActionsList. That component does useOnyx('report_null') (MoneyRequestReportActionsList.tsx:135) which returns undefined. It then crashes at line 543 accessing report.lastReadTime on undefined.

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

In ReportActionsList.tsx, add a guard for report.reportID alongside the existing !report check. When report.reportID is falsy (nullified by the optimistic leaveRoom update), return the skeleton view instead of passing a null reportID downstream to MoneyRequestReportActionsList or ReportActionsView. This prevents the crash during the brief window between the optimistic Onyx merge and navigation away from the report.

What alternative solutions did you explore?

1. Guard inside MoneyRequestReportActionsList: Add a null check for the report fetched via useOnyx and return early/skeleton if undefined. This is more defensive but treats the symptom rather than the source — the null reportID should never reach child components.
2. Prevent leaving IOU reports entirely: Modify canLeaveChat to disallow leaving IOU reports for invited participants. However, users should be able to leave reports they were invited to, so this would be overly restrictive.
3. Fix the leaveRoom optimistic data for IOU reports: Instead of nullifying reportID, use a different optimistic strategy (e.g., only hiding the participant). This is a larger change that affects the leave flow for all report types.

Investigation details

Crash chain:

1. leaveRoom sets reportID: null in optimistic data for non-workspace, non-thread reports
2. ReportActionsList check !report passes (object is truthy), isMoneyRequestReport(report) returns true (type 'iou' is preserved)
3. MoneyRequestReportActionsList receives reportID=null, does useOnyx('report_null') → returns undefined
4. Line 543: report.lastReadTime → TypeError on undefined

There are ~15 additional unguarded report.* accesses in MoneyRequestReportActionsList (lines 558, 579, 588, 651, 688, 692, 700, 750, 761, 779, 832, 839, 840) that would also crash.

The leaveRoom success data at line 4456-4462 also uses Onyx.METHOD.SET to replace the entire report with {reportName: report.reportName}, which is destructive for IOU reports where other participants still need the data. However, the crash occurs before this — during the optimistic phase.

canLeaveChat returns true for User C via isNonOwnerMangerOfIOUReport at ReportUtils.ts:11265-11268.

---

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 - @FitseTLT (External)

[melvin-bot]

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

[ReaperOAK]

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

Proposal

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

When an invited (chat-only) participant (User C) leaves an IOU report, the app crashes during the brief window between the optimistic Onyx update and the navigation away from the screen.

What is the root cause of that problem?

The crash originates in src/pages/inbox/ReportScreen.tsx and is caused by a race between the optimistic Onyx write and React re-rendering.

Step-by-step crash chain:

1. leaveRoom fires the optimistic update (src/libs/actions/Report/index.ts, L4399–4419).
   For non-workspace, non-thread reports (the IOU case), the optimistic data is:

   {
     onyxMethod: Onyx.METHOD.MERGE,
     key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
     value: {
       reportID: null,           // ← the culprit
       stateNum: CONST.REPORT.STATE_NUM.APPROVED,
       statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
       participants: { [currentUserAccountID]: { notificationPreference: HIDDEN } },
     },
   }

   This intentionally nullifies reportID to signal "report gone". Navigation via navigateToMostRecentReport is also called here — but it is async (React Navigation processes it in the next frame).

2. ReportScreen.tsx re-renders synchronously before navigation completes.
   reportOnyx (line 143, subscribed to report_${reportIDFromRoute}) receives the merge and its reportID field is now null. The memoized report object at line 170–218 explicitly copies reportID: reportOnyx.reportID, so report.reportID = null.

3. The !!report guard at lines 729–740 still passes because the report object itself is truthy — only its reportID field is null. React evaluates the JSX and renders:

   // line 728 (non-MoneyRequest path):
   <ReportActionsView reportID={report.reportID} />   // → reportID={null}
   
   // line 729–741 (MoneyRequest path — applies here since type='iou' is preserved):
   <MoneyRequestReportActionsList report={report} ... />  // → report.reportID=null

4. Inside MoneyRequestReportActionsList (src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx):
   const reportID = report?.reportID resolves to null. Every useOnyx call that concatenates this key now subscribes to a null-suffixed key instead of a valid collection entry:

   // line 207:
   const [reportNameValuePairs] = useOnyx(
     `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${getNonEmptyStringOnyxID(reportID)}`
   );  // → "report_name_value_pairsundefined" → undefined
   
   // line 208:
   const [reportMetadata] = useOnyx(
     `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`
   );  // → "report_metadatanull" → undefined

   Downstream render code (child components such as ReportActionsListItemRenderer, MoneyRequestReportTransactionList, and multiple useEffect hooks) then encounters state that was previously always non-null and crashes with a TypeError.

5. Why isMoneyRequestOrInvoiceReport stays true: The optimistic merge only sets reportID/stateNum/statusNum/participants. report.type is 'iou' and is not touched, so isMoneyRequestReport(report) still returns true, shouldDisplayMoneyRequestActionsList remains true, and MoneyRequestReportActionsList continues to be rendered with the broken data.

The skeleton guard on line 727 does not cover this case:

{(!report || shouldWaitForTransactions) && <ReportActionsSkeletonView />}

!report is false (the object is truthy) and shouldWaitForTransactions is also false (it depends on reportMetadata.isLoadingInitialReportActions which is already cached), so the skeleton is never shown during this window.

---

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

Single-file fix in src/pages/inbox/ReportScreen.tsx — extend the three existing render conditions to also guard against report.reportID being null.

// ── Before (lines 727–742) ───────────────────────────────────────────────────
{(!report || shouldWaitForTransactions) && <ReportActionsSkeletonView />}
{!!report && !shouldDisplayMoneyRequestActionsList && !shouldWaitForTransactions
  ? <ReportActionsView reportID={report.reportID} />
  : null}
{!!report && shouldDisplayMoneyRequestActionsList && !shouldWaitForTransactions ? (
    <MoneyRequestReportActionsList
        report={report}
        ...
    />
) : null}

// ── After ────────────────────────────────────────────────────────────────────
{(!report || !report.reportID || shouldWaitForTransactions) && <ReportActionsSkeletonView />}
{!!report && !!report.reportID && !shouldDisplayMoneyRequestActionsList && !shouldWaitForTransactions
  ? <ReportActionsView reportID={report.reportID} />
  : null}
{!!report && !!report.reportID && shouldDisplayMoneyRequestActionsList && !shouldWaitForTransactions ? (
    <MoneyRequestReportActionsList
        report={report}
        ...
    />
) : null}

Why this is correct:

• reportIDFromRoute (the URL parameter) never changes during this window — only the Onyx-merged report.reportID becomes null.
• Adding !!report.reportID to the render guards ensures that during the brief optimistic window (< one animation frame before navigation fires), the screen shows the existing ReportActionsSkeletonView instead of handing a null reportID to the two action-list components.
• No behavioral change for the normal case: when report.reportID is populated (always true outside the leaving window), the guards behave identically to before.
• No change to leaveRoom semantics, navigation logic, or any other component.

Defense-in-depth (optional, low risk): Also add an early return guard in src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx right after line with const reportID = report?.reportID;:

const reportID = report?.reportID;
if (!reportID) {
    return <ReportActionsSkeletonView />;
}

This makes MoneyRequestReportActionsList self-protecting so it can never crash on a null reportID regardless of how it is called in the future.

---

What alternative solutions did you explore? (Optional)

Alternative: Fix leaveRoom to avoid nullifying reportID for IOU/expense reports.
The optimistic reportID: null was introduced to trigger the "report removed" detection in the ReportScreen useEffect (the wasReportRemoved check). For workspace rooms and chat threads, a different path is already used (set notificationPreference: HIDDEN only, no reportID: null).

For an invited-chat-only participant leaving an IOU report, the same HIDDEN-preference path could apply — the user is being hidden from the report, not truly removed as a financial participant. Removing reportID: null from the else-branch for IOU/expense reports would prevent the null from ever reaching the render path.

However:

• This change touches leaveRoom shared logic used across multiple report types and could affect workspace-room leave, group chat leave, and other flows.
• The useEffect that drives navigation relies on wasReportRemoved = prevOnyxReportID === reportIDFromRoute && !onyxReportID — removing reportID: null from optimistic data would require verifying that the userLeavingStatus path (set by broadcastUserIsLeavingRoom) is sufficient to trigger navigation on its own for every platform/scenario.
• The existing skeleton-guard fix at the render layer is isolated to two lines in ReportScreen.tsx, has zero risk of regressions outside this specific render window, and is fully reversible.

The ReportScreen.tsx render-guard approach is therefore the safer, more surgical choice.

[emkhalid]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-11 15:04:47 UTC.

Proposal

Fix the bug at the source by keeping the optimistic IOU report valid during leaveRoom().

What is the root cause of that problem?

leaveRoom() temporarily makes a still-mounted report internally invalid by setting reportID: null before navigation finishes.

src/libs/actions/Report/index.ts

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

Lines 4442 to 4464 in 9a23626

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value:
	isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
	? {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	}
	: {
	reportID: null,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	},

value:
    isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
        ? {
              participants: {
                  [currentUserAccountID]: {
                      notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
                  },
              },
          }
        : {
              reportID: null,
              stateNum: CONST.REPORT.STATE_NUM.APPROVED,
              statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
              participants: {
                  [currentUserAccountID]: {
                      notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
                  },
              },
          },

That same Onyx entry is still being rendered while the app is navigating away. During that window, downstream consumers are still reading the current report, but that report now has an invalid internal shape because reportID is null.

In simple terms: the crash happens because the leave flow temporarily turns a live report into an invalid report object.

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

We should keep the optimistic report closed and hidden, but stop clearing its reportID.

src/libs/actions/Report/index.ts

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

Lines 4442 to 4464 in 9a23626

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value:
	isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
	? {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	}
	: {
	reportID: null,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	},

Replace the optimistic payload with this minimal change:

src/libs/actions/Report/index.ts
                     : {
-                          reportID: null,
                           stateNum: CONST.REPORT.STATE_NUM.APPROVED,
                           statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
                           participants: {
                               [currentUserAccountID]: {
                                   notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
                               },
                           },
                       },

This is enough because:

• the mounted IOU screen keeps reading a valid report object during the optimistic leave window
• the report is still marked closed and hidden immediately
• the existing success cleanup logic remains unchanged

We should not add any custom navigation logic for this issue. The bug is caused by malformed optimistic data, so the smallest and safest fix is to correct that data at the source.

What alternative solutions did you explore? (Optional)

Adding UI guards in ReportActionsList or MoneyRequestReportActionsList.
I did not choose this because it only hides the symptom after invalid optimistic data has already been written to Onyx.

Passing the route report ID deeper into the money request components.
I did not choose this because it works around one consumer of the bad data instead of fixing the optimistic payload itself.

Adding custom leave-navigation logic in ReportNavigateAwayHandler.
I did not choose this because it expands the scope beyond the issue, increases regression risk, and is unnecessary once the optimistic report shape is kept valid.

Proposal Demo

Screencast.From.2026-04-16.10-04-50.mp4

[Eskalifer1]

Proposal

Not a dupe, proposals above did not propose this as a solution

What is the root cause of that problem?

When a user leaves a report, the value of that report in Onyx becomes null:

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

Lines 4418 to 4440 in 7f504fc

	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value:
	isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
	? {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	}
	: {
	reportID: null,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	},
	},
	];

As a result, the entire report value is saved except for the reportID, so this check does not work:

App/src/pages/inbox/ReportActionsList.tsx

Lines 48 to 50 in 27c45fb

	if (!report || shouldWaitForTransactions) {
	return <ReportActionsSkeletonView />;
	}

This leads to the child component being certain that the report always exists:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 133 to 135 in 27c45fb

	// Self-subscribe to report, policy, metadata, actions, transactions
	// report is guaranteed to exist — callers only render this component when report is loaded
	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportIDProp}`) as unknown as [OnyxTypes.Report];

But the value of reportIDProp is undefined because it no longer exists, which means that report also becomes undefined here, and when attempting to retrieve its value, an error occurs:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Line 543 in 27c45fb

const reportLastReadTime = report.lastReadTime ?? '';

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

We can pass it to the child component here with a fallback to the ID from the route:

App/src/pages/inbox/ReportActionsList.tsx

Line 53 in f3b5db4

return <MoneyRequestReportActionsList reportID={report.reportID} />;

reportID={report.reportID ?? reportIDFromRoute}

PS: This can also be done in the child component

What alternative solutions did you explore? (Optional)

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.

[github-actions]

⚠️ @Eskalifer1 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[Eskalifer1]

Actually this might be regression from #87245, but i'm not sure