[Due for payment 2026-04-23] [$250] Performance: avoid double scan of reports in useParticipantsInvoiceReport

[mountiny]

Problem

useParticipantsInvoiceReport uses a custom Onyx selector (allInvoiceReportsSelector) that walks the entire COLLECTION.REPORT map (via mapOnyxCollectionItems) on every reports update to build a filtered "invoice rooms only" collection. That result is then compared (e.g. with deep equality) before a useMemo runs a second pass (Object.values(...).find(...)) to locate the matching invoice report for the receiver/policy.

So each reports change pays for:

1. A full-collection iteration + intermediate structure in the selector path
2. Another iteration in useMemo for matching

This hook is used on money-request / invoice-related flows (e.g. confirmation step, pay actions, report header), so the extra work shows up when opening those surfaces, especially on accounts with large report collections.

Expected outcome

• Subscribe to the full reports collection (or equivalent) without a redundant pre-filter selector that scans the whole map on every update.
• Perform invoice-room checks and receiver/policy matching in one pass inside useMemo (same behavior, fewer iterations and less allocation).

Implementation

Addressed in: #87580

QA / verification

• No change in which invoice report is resolved for a given receiver + policy.
• No new JS console errors on flows that call this hook (money request / pay invoice paths).
• Optional: profile before/after on a high–report-count account when opening money request.

Related

• PR: #87580 — Remove redundant selector loop in useParticipantsInvoiceReport

Issue Owner

Current Issue Owner: @hungvu193

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042756144459250432
• Upwork Job ID: 2042756144459250432
• Last Price Increase: 2026-04-11

[MelvinBot]

Issue Analysis

Root Cause: useParticipantsInvoiceReport performed two full iterations over the reports collection on every Onyx update:

1. Scan 1 (selector): allInvoiceReportsSelector called mapOnyxCollectionItems to build an invoice-only filtered map from the entire COLLECTION.REPORT — plus a deep-equality comparison on the result.
2. Scan 2 (useMemo): Object.values(...).find(...) iterated the filtered map again to match receiver/policy.

File: src/hooks/useParticipantsInvoiceReport.ts

Status: Already fixed in #87580 (merged 2026-04-11). The fix subscribes to the full COLLECTION.REPORT without a selector and combines the isInvoiceRoom check + receiver/policy matching into a single .find() pass inside useMemo, eliminating the intermediate allocation and redundant iteration.

Investigation details

Before (two passes):

Onyx update → selector: mapOnyxCollectionItems (scan all reports) → build filtered collection → deepEqual comparison → useMemo .find() (scan filtered reports) → return match

After (one pass):

Onyx update → useMemo .find() (scan all reports with isInvoiceRoom + matching inlined) → return match

Trade-off considered: Without the selector, every Onyx report update triggers useMemo re-evaluation (the allReports reference changes on any report update). Previously the selector + deepEqual might skip some useMemo runs if the invoice subset didn't change. In practice, the selector's full-collection scan on every update far outweighed this benefit, making the single-pass approach a net performance win (~60ms improvement reported on high-report-count accounts).

Behavioral correctness: The same guards are preserved — isInvoiceRoom, isArchivedNonExpenseReport, and identical receiver/policy matching logic — so no functional change.

---

Next Steps: This issue is already addressed by the merged PR. It can be closed once the fix is verified in production.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

useParticipantsInvoiceReport currently does extra work by scanning invoice reports more than once to derive a single participant’s invoice report, which adds avoidable overhead in large report collections.

What is the root cause of that problem?

The hook first builds allInvoiceReports by scanning all reports and filtering invoice reports in allInvoiceReportsSelector.

App/src/hooks/useParticipantsInvoiceReport.ts

Lines 21 to 32 in 1d43910

	const [allInvoiceReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT, {selector: allInvoiceReportsSelector});
	const [reportNameValuePairs] = useOnyx(ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS);
	const invoiceReport = useMemo(() => {
	const existingInvoiceReport = Object.values(allInvoiceReports ?? {}).find((report) => {
	if (!report || !reportNameValuePairs) {
	return false;
	}
	const isReportArchived = isArchivedReport(reportNameValuePairs[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report?.reportID}`]);
	if (isArchivedNonExpenseReport(report, isReportArchived)) {
	return false;
	}

Then it performs a second scan over that derived array with .find(...) inside useMemo to match managerID.

App/src/hooks/useParticipantsInvoiceReport.ts

Lines 36 to 40 in 1d43910

	(('accountID' in report.invoiceReceiver && report.invoiceReceiver.accountID === receiverID) ||
	('policyID' in report.invoiceReceiver && report.invoiceReceiver.policyID === receiverID));
	return report.policyID === policyID && isSameReceiver;
	});

mapOnyxCollectionItems(...) itself already iterates the collection once, so this pattern introduces an additional pass that is not needed when we only need one matched invoice report.
https://github.com/Expensify/App/blob/1d43910cc609b687312a6ea523b703579b201e6d/src/utils/mapOnyxCollectionItems.ts#L8-L14

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

1. Replace the current selector+find pattern with a single-pass selector that returns the first invoice report matching managerID.
2. Keep the report validity guards (reportSelector) and invoice filtering semantics unchanged.
3. Return early once a matching report is found to avoid extra scanning work.
4. Add a regression/perf-focused test to assert the hook still returns the same report while reducing per-render iteration work.

What alternative solutions did you explore? (Optional)

An alternative is caching allInvoiceReports more aggressively and keeping .find(...), but that still preserves the double-pass shape. A single-pass selector is simpler and reduces work deterministically.

[Ltbltbltbltb]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @Ltbltbltbltb 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.