[Due for payment 2026-07-08] [$250] [Performance] Investigate SendMessage metric improvements in chats with many MoneyRequestReportPreview

[mountiny]

Problem

When a report's action list contains common actions other than ADD_COMMENT — most notably money-request previews (MoneyRequestReportPreview) — sending a new message triggers more ReportActionItem child rerenders than necessary.
A plain ADD_COMMENT action item is relatively cheap and largely stable. But preview-style action items subscribe to additional Onyx data (the linked IOU/expense report, transactions, metadata) and do heavier work to render.

When ManualSendMessage fires, those items rerender even though their own underlying data did not change — so the per-send cost scales with how many expenses/previews the list already contains, not with the message being sent.
This is the inverse of the ADD_COMMENT stability work already done: those paths were stabilized, but the non-ADD_COMMENT action items have not received the same treatment.

Lead: #77176 (comment) — "Add multiple expenses in chat (MoneyRequestReportPreview) and send a message. We should reduce time spent on these rerenders. Maybe we could reuse getStableReportSelector."

Proposed direction

1. Build a report with multiple expenses (so the list holds several MoneyRequestReportPreview items), profile a ManualSendMessage, and capture which ReportActionItem children rerender and why.
2. For non-ADD_COMMENT item type, find the Onyx subscriptions that re-emit on every message/read but whose churning fields the subtree never reads.
3. Try to stabilize it, replace any whole-collection or unselected REPORT/related subscriptions with scoped, selector-backed ones. Check memoization and decomposition opportunities.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067137258223829945
• Upwork Job ID: 2067137258223829945
• Last Price Increase: 2026-06-17

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The inbox list (ReportActionsList) already passes its report/chatReport down through getStableReportSelector, which strips the volatile fields that churn on every send (lastMessageText, lastVisibleActionCreated, lastReadTime, lastReadSequenceNumber, lastActorAccountID, lastActionType, …). That's the #77176 stabilization, and it lets the memoized row renderer bail for unchanged siblings.

But the MoneyRequestReportPreview subtree re-subscribes to the raw chat report (and other raw report keys) inside the row, bypassing that stabilization. When you send a message, addComment writes the new action and updates those exact last* fields on REPORT_<chatReportID>. Every unselected useOnyx(REPORT_<chatReportID>) in the preview re-emits a new object reference, so the preview and its action buttons rerender even though nothing they actually read changed. Cost scales with the number of preview cards in the list, not with the message being sent.

Offending subscriptions (verified at 257cd2d)

Raw chat-report subscriptions whose consumers only read stable fields (invoiceReceiver, isPolicyExpenseChat, isInvoiceRoom, ownerAccountID, …):

• MoneyRequestReportPreview/index.tsx:45 — useOnyx(REPORT_${chatReportID}), no selector
• MoneyRequestReportPreview/ReportPreviewActionButton.tsx:70
• MoneyRequestReportPreview/PayActionButton.tsx:77
• TransactionPreview/index.tsx:38 — multiplied by N carousel cards

Other unscoped subscriptions that re-emit on the same send / on unrelated writes:

• useReportWithTransactionsAndViolations.ts:15 — raw useOnyx(REPORT_${reportID}) for the iouReport
• MoneyRequestReportPreviewContent.tsx:111 — REPORT_METADATA_${chatReportID} unscoped (only isOptimisticReport is read); index.tsx:120 already scopes its metadata sub with pendingNewTransactionIDsSelector, the pattern to copy
• MoneyRequestReportPreviewContent.tsx:112 — RAM_ONLY_REPORT_LOADING_STATE unscoped (only hasOnceLoadedReportActions read; index.tsx:117 already scopes this)
• MoneyRequestReportPreviewContent.tsx:135 — whole TRANSACTION_VIOLATIONS collection (also unscoped in ReportPreviewActionButton, ApproveActionButton, SubmitActionButton, PayActionButton)

getStableReportSelector and its ExcludedFields list: selectors/Report.ts:100-190.

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

Apply the existing getStableReportSelector (and narrow per-field selectors) to the in-row report subscriptions so they stop re-emitting on the volatile last* fields, mirroring what the list already does for the ADD_COMMENT path:

1. Add {selector: getStableReportSelector} to the raw useOnyx(REPORT_${chatReportID}) subscriptions in MoneyRequestReportPreview/index.tsx:45, ReportPreviewActionButton.tsx:70, PayActionButton.tsx:77, and TransactionPreview/index.tsx:38. None of these consumers read the stripped fields.
2. Add {selector: getStableReportSelector} to the iouReport subscription in useReportWithTransactionsAndViolations.ts:15 (confirm no consumer reads last* off the returned report).
3. Scope MoneyRequestReportPreviewContent.tsx:111-112 to the single fields they read (isOptimisticReport, hasOnceLoadedReportActions) — selectors for both already exist on the index.tsx siblings.
4. Optionally scope the whole-collection TRANSACTION_VIOLATIONS subscriptions to the relevant report's transactions.

Then profile a ManualSendMessage in a report with several expenses (React Profiler) to confirm the per-send rerender count drops.

What alternative solutions did you explore? (Optional)

Wrapping ReportActionItem/MoneyRequestReportPreview in tighter React.memo comparators would help, but it doesn't fix the leak — the in-row subscriptions hand the memo a new report reference every send, so the comparator would still see changed props. Scoping the subscriptions is the root-cause fix; memo tightening is at best complementary.

Confidence & how this was validated

High confidence. Two independent investigations converged on the same leak, and the offending lines were byte-verified: the raw useOnyx(REPORT_…) calls have no selector, and getStableReportSelector's ExcludedFields is exactly the set of fields mutated by addComment. Not yet validated: a before/after Profiler trace quantifying the rerender reduction — recommended as the PR's test evidence.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

Every MoneyRequestReportPreview in a chat subscribes to the full parent chat report with no selector:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Line 45 in 257cd2d

const [chatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);

All previews in the same chat share the same chatReportID, so they all subscribe to the same report object. When ManualSendMessage fires, the chat report's heartbeat fields (lastMessageText, lastVisibleActionCreated, lastReadTime, lastActorAccountID, etc.) are written → the unscoped useOnyx re-emits a new object for every preview → each MoneyRequestReportPreview (and its heavy transaction/IOU subtree) rerenders. So the per-send cost scales with the number of previews, not the message.

The component only ever reads two stable fields from that report — invoiceReceiver in index.tsx and ownerAccountID in the content:

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Line 263 in 257cd2d

accountID: chatReport?.ownerAccountID,

— neither of which changes on send. The last* churn fields are never read, yet they drive the rerender. This is exactly the gap getStableReportSelector already closes for ADD_COMMENT/ReportActionItem, whose excluded fields are precisely these heartbeat keys:

App/src/selectors/Report.ts

Lines 100 to 112 in 257cd2d

	type ExcludedFields = ValidReportKeys<
	[
	'lastMessageText',
	'lastVisibleActionCreated',
	'lastReadTime',
	'lastReadSequenceNumber',
	'lastMentionedTime',
	'lastVisibleActionLastModified',
	'lastMessageHtml',
	'lastActorAccountID',
	'lastActionType',
	]
	>;

ReportActionItem already applies the stable selector to its own report subscription, but MoneyRequestReportPreview was never given the same treatment.

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

Reuse getStableReportSelector on the chat report subscription so the preview only re-emits when a field it actually reads changes, not on chat heartbeat:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Line 45 in 257cd2d

const [chatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);

i.e. pass {selector: getStableReportSelector} to that useOnyx. Both fields the subtree consumes (invoiceReceiver, ownerAccountID) are already in the projection, so this is safe and eliminates the per-send rerenders.

The same unscoped pattern exists for the linked expense report here:

App/src/hooks/useReportWithTransactionsAndViolations.ts

Line 15 in 257cd2d

const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportID}`);

This one is per-row rather than shared, so it doesn't scale with ManualSendMessage, but it can be stabilized the same way to cut secondary churn — verify its consumers don't read excluded fields before scoping it.

What alternative solutions did you explore? (Optional)

Wrap MoneyRequestReportPreviewContent in React.memo with a custom comparator — but that only masks the wasted re-emits downstream and still recomputes derived values in index.tsx on each emit. Scoping the subscription with the selector removes the churn at the source, matching the existing ADD_COMMENT stabilization approach.

[dilshodmackbook-sketch]

Proposal

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

In chats containing MoneyRequestReportPreview items, sending a message (ManualSendMessage) rerenders those previews even though their own data didn't change, so the per-send cost scales with the number of expense previews in the list.

What is the root cause of that problem?

MoneyRequestReportPreview subscribes to the full chat report, with no selector:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Line 45 in 257cd2d

const [chatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);

The preview lives in that chat's action list, and ManualSendMessage writes the chat report's "heartbeat" fields (lastMessageText, lastVisibleActionCreated, lastVisibleActionLastModified, lastActorAccountID, lastActionType, …) on every send. Because the subscription has no projection, Onyx re-emits the whole chatReport object on each of those writes, rerendering MoneyRequestReportPreview and its entire MoneyRequestReportPreviewContent subtree.

These are exactly the fields the stable projection already strips out:

App/src/selectors/Report.ts

Lines 100 to 112 in 257cd2d

	type ExcludedFields = ValidReportKeys<
	[
	'lastMessageText',
	'lastVisibleActionCreated',
	'lastReadTime',
	'lastReadSequenceNumber',
	'lastMentionedTime',
	'lastVisibleActionLastModified',
	'lastMessageHtml',
	'lastActorAccountID',
	'lastActionType',
	]
	>;

And the preview only ever reads stable fields off chatReport — invoiceReceiver here:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Lines 46 to 48 in 257cd2d

	const invoiceReceiverPolicyID = chatReport?.invoiceReceiver && 'policyID' in chatReport.invoiceReceiver ? chatReport.invoiceReceiver.policyID : undefined;
	const [invoiceReceiverPolicy] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${getNonEmptyStringOnyxID(invoiceReceiverPolicyID)}`);
	const invoiceReceiverPersonalDetail = chatReport?.invoiceReceiver && 'accountID' in chatReport.invoiceReceiver ? personalDetailsList?.[chatReport.invoiceReceiver.accountID] : null;

…and chatType / isOwnPolicyExpenseChat / tripData / policyID / policyName / ownerAccountID inside the content (via isPolicyExpenseChat, isInvoiceRoom, isTripRoom, getPolicyName, getInvoicePayerName, ownerAccountID):

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 213 to 215 in 257cd2d

	const isPolicyExpenseChat = isPolicyExpenseChatReportUtils(chatReport);
	const isInvoiceRoom = isInvoiceRoomReportUtils(chatReport);
	const isTripRoom = isTripRoomReportUtils(chatReport);

None of those are in the excluded last* set, so every one of these heartbeat re-emits is wasted work. This is the same churn the ADD_COMMENT path already fixed with getStableReportSelector — the preview path just never got the treatment.

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

Subscribe to the chat report through getStableReportSelector, exactly as ReportActionsList / ReportActionItem already do, so the last* heartbeat writes no longer re-emit to the preview:

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 194 to 196 in 257cd2d

	const stableReportSelector = useCallback((reportEntry: OnyxEntry<OnyxTypes.Report>) => getStableReportSelector(reportEntry), []);
	const [reportStable] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`, {selector: stableReportSelector});
	const [chatReportStable] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(reportStable?.chatReportID)}`, {selector: stableReportSelector});

const [chatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`, {selector: getStableReportSelector});

Every chatReport field the preview/content reads (invoiceReceiver, chatType, isOwnPolicyExpenseChat, tripData, policyID, policyName, oldPolicyName, ownerAccountID) is already part of the projection, so this is behavior-preserving.

Additionally, the IOU/expense report the preview renders is subscribed full (no selector) in useReportWithTransactionsAndViolations:

App/src/hooks/useReportWithTransactionsAndViolations.ts

Line 15 in 257cd2d

const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportID}`);

If profiling a multi-expense ManualSendMessage still shows preview churn after the chat-report fix, we should apply the same getStableReportSelector projection there (the preview reads only stable fields off the IOU report — total, currency, stateNum/statusNum, etc., all in the projection). We can scope that in the PR phase since the hook is shared; the chat-report change is the direct hit for the SendMessage metric.

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

A render-count / Reassure perf test: in a report holding several MoneyRequestReportPreview items, firing ManualSendMessage should not rerender the preview subtrees (their props / selected report projection are unchanged), and the per-send cost should stay flat as the number of previews grows.

What alternative solutions did you explore? (Optional)

Wrapping MoneyRequestReportPreviewContent in a deeper React.memo with a custom comparator — rejected because it only masks the wasted re-emit (the parent still re-renders and rebuilds props / renderItem), whereas stripping the heartbeat fields at the subscription stops the invalidation at the source, consistent with the existing getStableReportSelector pattern.

[ahmdshrif]

Proposal

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

In chats that contain many MoneyRequestReportPreview components, the SendMessage performance metric regresses. Sending a message re-renders the report action list, and every preview re-renders unnecessarily, inflating the measured time.

What is the root cause of that problem?

The MoneyRequestReportPreview wrapper recomputes several non-referentially-stable props on every render and forwards them to its child, so none of the previews can bail out of re-rendering when an unrelated action (a new message) is appended to the list:

• newTransactionIDs is rebuilt as a brand-new Set on every render: index.tsx#L125
• renderItem (the FlashList renderItem) and transactionPreviewContainerStyles are recreated inline each render: index.tsx#L127-L148
• Neither the wrapper nor MoneyRequestReportPreviewContent is wrapped in React.memo: index.tsx#L180, MoneyRequestReportPreviewContent.tsx#L808. With unstable props this cascade reaches each TransactionPreview in the carousel, multiplied across every preview in the chat.

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

Stabilize the props and memoize the components so an unrelated list update no longer re-renders every preview:

// index.tsx
const newTransactionIDs = useMemo(
    () => new Set(newTransactions.map((t) => t.transactionID)),
    [newTransactions],
);
const transactionPreviewContainerStyles = useMemo(
    () => [styles.h100, reportPreviewStyles.transactionPreviewCarouselStyle],
    [styles.h100, reportPreviewStyles.transactionPreviewCarouselStyle],
);
const renderItem: ListRenderItem<Transaction> = useCallback(({item}) => (/* ...unchanged... */), [/* deps */]);

export default React.memo(MoneyRequestReportPreview);

Also wrap MoneyRequestReportPreviewContent in React.memo. Regression risk: ensure the memo deps (transactions, widths, new-transaction highlight Set) stay in the dependency arrays so a genuinely new/highlighted transaction still re-renders.

[melvin-bot]

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