[Due for payment 2026-09-09] [Exploratory] Page crashes when duplicating reports which have 50+ expense in each of them

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.56-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: #98556
Email or phone of affected tester (no customers): emady.syed1234+daddu@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

Precondition: Create few reports with 50+ expense in each of them

1. Open staging.new.expensify
2. Go to spend > reports
3. Select more than 15 reports from precondition > Duplicate them

Expected Result:

Page should be responsive

Actual Result:

Page crashes when duplicating report which have 50+ expense in it

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7237191_1787140359307.Recording__1089.mp4

logs.txt

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @nkdengineer

[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/ed5366ffc0be54750da024b8b3ff0ce7c9e136a98d49d449134f0efff68c8afd

[mukhrr]

@luacmartins can we (with @nkdengineer ) get assigned here since this was found while QA testing PR #98556 ?! thanks

RCA:
bulkDuplicateReports builds the entire selection in one synchronous tick. So one click producing 6 writes (2 CreateAppReport, 1 RequestMoney, 3 CreateDistanceRequest) blocked the main thread for 488ms, and that was the only gap above 200ms in the run. That's ~120ms per duplicated expense → ~90s single-tick at the reported 750. Nothing flushes during it: API.write applies optimistic Onyx data synchronously (src/libs/deferredLayoutWrite.ts:8-9) and PersistedRequests.save persists via an async Onyx.set that can't resolve while the loop holds the tick, so all 750 payloads sit in memory and a crash mid-build loses everything.

Solution:
async function bulkDuplicateReports, loop selectedReportsParam.entries(), await a setTimeout(0) before every iteration after the first.

[luacmartins]

Sure. @nkdengineer can you comment on this issue so I can assign you?

[nkdengineer]

@luacmartins Sure.

[mukhrr]

Proposal

What is the root cause of that problem?

bulkDuplicateReports() walks the entire selection in one synchronous pass, and every eligible expense inside every selected report gets its own API.write:

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

Lines 1404 to 1425 in 3dc2897

	for (const selectedReport of selectedReportsParam) {
	const reportID = selectedReport.reportID;
	if (!reportID) {
	continue;
	}
	const snapshotReport = searchData?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] as OnyxTypes.Report | undefined;
	const onyxReport = allReports[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
	const report = snapshotReport ?? onyxReport ?? (selectedReport as OnyxTypes.Report);
	const reportTransactions = transactionsByReportID.get(reportID) ?? [];
	if (!snapshotReport && !onyxReport && reportTransactions.length === 0) {
	continue;
	}
	const reportPolicy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const isSourcePolicyValid = !!reportPolicy && isPolicyAccessible(reportPolicy, currentUserLogin);
	const chatReportID = report.chatReportID ?? report.parentReportID;
	const chatReport = chatReportID
	? ((searchData?.[`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`] as OnyxTypes.Report | undefined) ?? allReports[`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`])
	: undefined;

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

Lines 1066 to 1080 in 3dc2897

	for (let i = 0; i < eligibleTransactions.length; i++) {
	const transaction = eligibleTransactions.at(i);
	if (!transaction) {
	continue;
	}
	const transactionDetails = getTransactionDetails(transaction);
	if (!transactionDetails) {
	continue;
	}
	const isLastExpense = i === eligibleTransactions.length - 1;
	const {transactionParams, waypoints} = buildDuplicateTransactionParams(transaction, transactionDetails);
	const params: RequestMoneyInformation = {
	report: parentChatReport,

I put a selection of reports through this on dev web with a probe on the main thread and watched what the loop actually costs:

• The click on Duplicate reports produced six writes (2 CreateAppReport, 1 RequestMoney, 3 CreateDistanceRequest) and every one of them was built inside a single uninterrupted 488ms tick.
• That 488ms was the only gap above 200ms in the whole run, so it is the loop itself blocking, not rendering afterwards. Four duplicated expenses, ~120ms of blocking each.
• At the reported scale, 15 reports x 50 expenses is 750 of those, which is roughly 90 seconds of unbroken synchronous work in one tick. Nothing can paint, no input is handled, and the tab is what the tester saw die.

Two things are trapped behind that tick, and both matter more than the raw CPU time. API.write() applies optimistic Onyx data synchronously, which the repo already documents as a JS-thread hazard:

App/src/libs/deferredLayoutWrite.ts

Lines 5 to 12 in 3dc2897

	/**
	* Coordinates deferred API.write() calls with screen content layout transitions.
	*
	* Problem: API.write() applies optimistic Onyx data synchronously, which triggers
	* expensive collection-level re-renders. When navigating to a screen after an action
	* like expense creation, firing this during the skeleton->content transition blocks
	* the JS thread and makes the skeleton hang.
	*

And each write is persisted by rewriting the whole growing queue through an async Onyx.set, which cannot resolve while the loop holds the thread:

App/src/libs/actions/PersistedRequests.ts

Lines 245 to 259 in 3dc2897

	const requests = [...persistedRequests, requestToPersist];
	const previousLength = persistedRequests.length;
	persistedRequests = requests as AnyRequest[];
	const requestIndex = getClientRequestIndex(requestToPersist as AnyRequest);
	if (requestIndex != null) {
	knownRequestIDs.add(requestIndex);
	}
	Log.info('[PersistedRequests] Request added to memory, persisting to disk', false, {
	command: requestToPersist.command,
	previousQueueLength: previousLength,
	newQueueLength: requests.length,
	});
	return trackOnyxWrite(Onyx.set(ONYXKEYS.PERSISTED_REQUESTS, requests as AnyRequest[]))

So all 750 requests, each carrying its own optimistic, success and failure data, accumulate in memory before a single one reaches disk or the network. The queue never drains during the operation because the callbacks that would drain it cannot run.

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

Make bulkDuplicateReports() hand the thread back between reports, so the browser can paint and the request queue can drain instead of the whole selection being assembled in one pass:

-function bulkDuplicateReports({
+async function bulkDuplicateReports({
...
-    for (const selectedReport of selectedReportsParam) {
+    for (const [index, selectedReport] of selectedReportsParam.entries()) {
+        if (index > 0) {
+            // eslint-disable-next-line no-await-in-loop
+            await new Promise<void>((resolve) => {
+                setTimeout(resolve, 0);
+            });
+        }

Putting the yield at the top of the iteration rather than the bottom keeps every existing continue in the loop body untouched, so the eligibility and policy-fallback rules are unchanged. playSound(SOUNDS.DONE) stays after the loop and now fires when the selection is genuinely finished. The only caller is useBulkDuplicateReportAction, which already fires this without awaiting, and clearSelectedTransactions after it is safe because the selection array is captured by value when the call starts.

I verified this against the real code path. A regression test that selects three reports asserts one CreateAppReport and one RequestMoney exist synchronously after the call and three of each after awaiting it. On current main it fails with Expected: 1, Received: 3, because all three reports are duplicated before the call returns; with the change it passes, and the other 67 tests in DuplicateTest.ts pass either way. Ten existing bulkDuplicateReports(...) call sites in that file needed an await added, which is a mechanical change that is correct on both versions.

One thing I want to be straight about: this removes the aggregate single-tick build, it does not make the flow smooth. A single report of 50 expenses still assembles in one pass, around six seconds by the per-expense number above. The value is that the tab survives, each report's requests reach disk before the next one starts, and progress is no longer all-or-nothing.

What alternative solutions did you explore? (Optional)

The durable fix is one DuplicateReports write command carrying the selected report IDs, with the backend running the existing eligibility checks and returning Onyx data in a single response. That is not something I can ship from App, and the codebase says why: bulk actions on Search are blocked behind the 1:1:1 migration, which is exactly the note left on submitMoneyRequestOnSearch.

App/src/libs/actions/Search.ts

Lines 1325 to 1333 in 3dc2897

	{
	...backendQueryJSON,
	searchKey,
	filters: backendQueryJSON.filters ?? null,
	},
	exactMatchFilterKeys ? new Set(exactMatchFilterKeys) : undefined,
	);
	read(

I want to correct my own earlier reasoning here. I had dismissed yielding on the grounds that it could leave part of the selection unscheduled if the app is killed mid-way. Reading PersistedRequests.save inverts that objection. The current synchronous loop persists nothing until all 750 requests are built, so a crash during the build, which is the reported outcome, loses the entire selection. Yielding gets each report's requests onto disk before the next one begins, so a mid-way failure keeps the work already queued.

Capping how many reports can be selected would hide the scalability problem without fixing it, and it takes a working feature away from the users most likely to want it. Yielding inside duplicateReport()'s per-expense loop as well would smooth the single-report case too, but that helper is on the single-report path and widening it is better handled once the bulk command lands.

[mukhrr]

@nkdengineer do you think proposal makes sense and we can continue? thanks

[nkdengineer]

@luacmartins Currently, when duplicating the report with X transaction, we do this flow: CreateAppReport --> Y RequestMoney. Then, if we bulk-duplicate X reports, we call X*Y API. Is it better to combine X RequestMoney into a new API?