[$250] DEV: Report Preview Not Updating After Adding Expense Until Manual Refresh

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce in staging)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @FitseTLT
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open a report in New Expensify with few expneses
2. Add a new expense to the existing report
3. Return to the report list or observe the report preview

Expected Result:

Report preview should update in real-time to reflect:
Updated total
Newly added expense

Actual Result:

Updates only appear after:
Manual refresh, or

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

Screenshots/Videos

2026-04-06.22-58-46.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @FitseTLT

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041253090848970252
• Upwork Job ID: 2041253090848970252
• Last Price Increase: 2026-04-06

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two contributing issues:

1. LHN preview text uses stale server-provided report name for workspace chats

When a REPORT_PREVIEW action is the last action in a workspace chat, the LHN preview text is set from reportAttributesDerived?.[iouReport.reportID]?.reportName (OptionsListUtils/index.ts:721). For expense-type reports (created by workspace chats), computeReportName returns the server-provided report.reportName directly without recomputing from report.total (ReportNameUtils.ts:896-898). So even though report.total is updated optimistically when an expense is added (IOU/index.ts:2553-2586), the displayed name in the LHN doesn't reflect the new total until the server pushes an updated reportName.

2. lastVisibleActionCreated not updated on the chat report for existing expense reports

At IOU/index.ts:1746, the optimistic data only sets lastVisibleActionCreated on the chat report when creating a new money request report (shouldCreateNewMoneyRequestReport ? {lastVisibleActionCreated: ...} : {}). When adding an expense to an existing report, the chat's timestamp is not updated, so the LHN doesn't re-sort the chat to reflect new activity.

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

Fix 1: In computeReportName (ReportNameUtils.ts:896-898), when the report has pendingFields.preview (indicating an optimistic update is in progress), recompute the name from report.total instead of returning the stale server-provided reportName. This ensures the LHN preview text reflects the updated total immediately.

Fix 2: At IOU/index.ts:1746, always set lastVisibleActionCreated on the chat report when adding an expense, not just when creating a new money request report. Change the conditional to always include the timestamp:

lastVisibleActionCreated: chat.reportPreviewAction.created,

What alternative solutions did you explore? (Optional)

An alternative for Fix 1 would be to update report.reportName optimistically in the IOU action (buildOnyxDataForMoneyRequest) alongside the report.total update. This would keep computeReportName simple but would require computing the formatted report name string in the action layer.

Supporting evidence

• The REPORT_PREVIEW action itself IS updated optimistically with new message text and childMoneyRequestCount via updateReportPreview at ReportUtils.ts:7724-7776
• The iouReport total IS updated optimistically at IOU/index.ts:1755-1766
• getMoneyRequestSpendBreakdown reads report.total directly at ReportUtils.ts:4385, and the inline MoneyRequestReportPreviewContent component uses this reactively at MoneyRequestReportPreviewContent.tsx:168 — so the inline preview likely updates, but the LHN does not
• Additionally, getTransactionsWithReceipts in MoneyRequestReportPreviewContent.tsx:188 and getReportTransactions in ReportPreviewActionButton.tsx:75 read from a deprecated non-reactive module-level cache (deprecatedReportsTransactions at ReportUtils.ts:1154), which could cause stale receipt/button state in the inline preview

---

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/~022041253090848970252

[Ltbltbltbltb]

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

When a new expense is added to a report in a workspace chat, the report preview carousel does not update to show the new transaction count or updated total until a manual refresh.

What is the root cause of that problem?

Two-layer bug:

1. Latent mutation in reportTransactionsAndViolations.ts (since PR #65247):
The compute function at line 32 does const reportTransactionsAndViolations = currentValue ?? {} and then mutates that object in-place throughout the loop (adding/deleting keys directly on it), then returns the same object reference. This means the return value of compute is the same JS object identity as currentValue.

2. Onyx structural sharing introduced in react-native-onyx 3.0.57 (PR #765, merged 2026-03-31):
fastMerge now uses structural sharing — when the incoming value is identical to the stored value, it preserves the existing object reference instead of creating a new one. Because compute mutates currentValue in-place and returns it, fastMerge sees the same reference and preserves it. useOnyx uses shallowEqual for change detection: same object reference → no state update → no re-render → stale carousel.

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

Fix the mutation in src/libs/actions/OnyxDerived/configs/reportTransactionsAndViolations.ts so the compute function always returns a new object reference instead of mutating currentValue in-place.

Specifically, line 32 should spread currentValue into a new object: const reportTransactionsAndViolations = currentValue ? {...currentValue} : {}. The nested transactions and violations objects for each reportID that gets modified in the loop should also be shallow-copied before mutation to ensure referential inequality at every level that changed.

This is the minimal fix: it restores the invariant that compute returns a new reference when the value has changed, which is what Onyx's structural sharing and useOnyx's shallowEqual both depend on to correctly detect updates and trigger re-renders.

Contributor Details

Field	Value
Contributor email	lucastrba@gmail.com
Upwork Profile	https://www.upwork.com/freelancers/~01d016059c6701ebaa

[FitseTLT]

@MelvinBot the issue is that the number of expense/carouselTransactions in the report preview carousel is only updated after page refresh

[wildan-m]

Proposal

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

When adding a new expense to an existing report in a workspace chat, the LHN report preview does not update to reflect the new total until a manual refresh.

What is the root cause of that problem?

There are two early returns in ReportNameUtils.ts that return the stale server-provided report.reportName for expense reports, even when the report's total has already been updated optimistically:

1. computeReportName — first early return

App/src/libs/ReportNameUtils.ts

Lines 896 to 898 in 0570251

	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
	return report?.reportName;
	}

This returns the server-provided report.reportName for all expense-type reports, regardless of whether the report is in the middle of an optimistic update. Even though report.total is updated optimistically in buildOnyxDataForMoneyRequest, this early return short-circuits the dynamic name computation.

2. getMoneyRequestReportName — second early return

App/src/libs/ReportNameUtils.ts

Lines 373 to 375 in 0570251

	if (report?.reportName && isExpenseReport(report)) {
	return report.reportName;
	}

Even if the first early return is bypassed, the code reaches getMoneyRequestReportName via isMoneyRequestReport(report) at line 964, which has the same stale report.reportName early return. Both barriers must be removed for the dynamic computation (using getMoneyRequestSpendBreakdown → report.total) at line 377 to run.

The optimistic data at IOU/index.ts correctly updates report.total and sets pendingFields.preview to signal an in-progress update:

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

Lines 1755 to 1766 in 0570251

	onyxData.optimisticData?.push(
	{
	onyxMethod: shouldCreateNewMoneyRequestReport ? Onyx.METHOD.SET : Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${iou.report.reportID}`,
	value: {
	...iou.report,
	lastVisibleActionCreated: iou.action.created,
	pendingFields: {
	...(shouldCreateNewMoneyRequestReport ? {createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD} : {preview: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE}),
	},
	},
	},

The derived report attributes config at reportAttributes.ts correctly picks up the IOU report change and propagates to the parent chat report (lines 192-201). But computeReportName returns the stale reportName, so the derived value's reportName field remains unchanged, and the LHN preview text at OptionsListUtils/index.ts:721 reflects the old total.

Additionally, lastVisibleActionCreated is not updated on the chat report when adding to an existing expense report:

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

Line 1746 in 0570251

...(shouldCreateNewMoneyRequestReport ? {lastVisibleActionCreated: chat.reportPreviewAction.created} : {}),

The conditional only sets lastVisibleActionCreated when creating a new money request report. For existing reports, the chat report's timestamp remains stale, so it doesn't re-sort to the top of the LHN to reflect the new activity.

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

Fix 1 — Skip stale early returns during optimistic updates. The pendingFields.preview flag is already set on the IOU report during optimistic updates (line 1763) and cleared in successData (line 2059). Use it as a gate:

In computeReportName (line 896), change the condition to:
if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE && !report?.pendingFields?.preview)

In getMoneyRequestReportName (line 373), change the condition to:
if (report?.reportName && isExpenseReport(report) && !report?.pendingFields?.preview)

When pendingFields.preview is set, both early returns are skipped and the code reaches the dynamic computation at line 377 which uses getMoneyRequestSpendBreakdown(report).totalDisplaySpend — this reads the already-updated report.total and formats the correct amount. Once the server responds, pendingFields is nulled and the fresh server-provided reportName is used again.

Fix 2 — Always update lastVisibleActionCreated on the chat report. At line 1746, change the conditional to always include the timestamp, using the new IOU action's created time for existing reports so the chat correctly re-sorts to the top of the LHN.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87179-report-preview-not-updating?expand=1

What alternative solutions did you explore? (Optional)

An alternative for Fix 1 is to optimistically compute and set report.reportName alongside report.total in buildOnyxDataForMoneyRequest. This would keep the early returns unchanged but requires replicating the name formatting logic (getMoneyRequestReportName) in the action layer. The pendingFields.preview approach is simpler — it leverages the existing dynamic computation path and the flag that's already set and cleared by the optimistic data lifecycle.

[MelvinBot]

Thanks for the clarification, FitseTLT. The specific issue is the carousel transaction count not updating. I've revised my analysis:

Proposal (Updated)

What is the root cause of that problem?

The compute function in reportTransactionsAndViolations.ts:32,85 mutates currentValue in-place and returns the same object reference:

const reportTransactionsAndViolations = currentValue ?? {};
// ... mutates reportTransactionsAndViolations[reportID].transactions[transactionKey] = transaction;
return reportTransactionsAndViolations;  // same reference as currentValue

Although Onyx's derived value system always broadcasts updates (skipCacheCheck: true at utils.ts:24), the useOnyx hook applies shallowEqual to decide whether to trigger a React state update (useOnyx.js:205). Since previousValueRef.current already points to the same mutated object, shallowEqual(obj, obj) short-circuits via a === b → true, so no state update occurs.

This means the context provider (createOnyxContext.tsx) never re-renders, useReportWithTransactionsAndViolations returns stale data, and carouselTransactions/numberOfRequests in MoneyRequestReportPreviewContent.tsx:187,326 don't update until a full page refresh creates fresh object references.

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

In reportTransactionsAndViolations.ts, stop mutating currentValue in-place. Instead, create new object references when changes occur so that shallowEqual in useOnyx detects the change:

1. Shallow-clone the top-level object: const result = {...(currentValue ?? {})}
2. When modifying a reportID's entry, create a new entry: result[reportID] = { transactions: {...existing.transactions, [transactionKey]: transaction}, violations: {...existing.violations} }
3. Return the new result reference

This ensures shallowEqual(previousValue, newValue) returns false when transactions are added/removed, triggering the context update and re-rendering the carousel.

What alternative solutions did you explore? (Optional)

• Adding a custom selector with useOnyx to force deep comparison — this would work but is less efficient and harder to maintain than fixing the mutation at the source.
• Using Onyx.set without skipCacheCheck and relying on deepEqual — but skipCacheCheck is an intentional optimization for derived values, so the fix should be at the compute level.

---

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.

[wildan-m]

Proposal

Updated

Added compare branch with implementation.