[$250] Bulk expense edit hangs and crashes on large reports

[marcaaron]

Problem

When a report has many expenses (40-50+), if you bulk edit them (e.g. toggle billable to false for all), the UI hangs noticeably and the browser tab can become unresponsive.

Solution

Two changes needed here:

• The bulk edit flow makes an unnecessary report reload after each individual expense update, causing a flood of operations. This call should be removed.
• The save button should show a loading spinner while the edits are processing so users know something's happening and don't keep clicking.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054987899835140509
• Upwork Job ID: 2054987899835140509
• Last Price Increase: 2026-05-14

[marcaaron]

Dug into the root cause a bit. The performance problem is coming from createTransactionThreadReport being called inside the bulk edit loop for each expense that doesn't already have a local transaction thread (i.e. has never been individually opened). That function unconditionally calls openReport, which fires an OpenReport API command AND does a batch of Onyx writes per expense (a SET on the report, a SET on report actions, isLoadingInitialReportActions: true on REPORT_METADATA, etc.). On a report with 40-50 expenses that have never been clicked open, every single one hits this path, so you end up with up to 50 OpenReport calls stacked on top of 50 UpdateMoneyRequest calls. The synchronous Onyx writes from all those openReport calls in rapid succession are what hangs the main thread.

The good news is the OpenReport call is completely unnecessary here. The Auth backend already creates the transaction thread when it doesn't exist as part of processing UpdateMoneyRequest — MoneyRequest::createModifiedActionAndUpdateReportPreview checks transactionThreadReportID == 0 and calls createTransactionThread itself before writing the MODIFIED_EXPENSE action. The user is also never navigated to the thread, so there's nothing to fetch from the server anyway.

The fix should be to replace the createTransactionThreadReport call in the bulk edit loop with a lighter local-only setup that just writes the optimistic thread and CREATED action to Onyx directly, without firing any API command. One thing to double-check: the existing CREATED action backfill logic in the loop (BulkEdit.ts around line 433) currently skips writing a CREATED action when the thread was "just created above" (because openReport handles it). After the change, that guard will need to be updated so the CREATED action is always written locally.

[marcaaron]

@MelvinBot Can you implement a fix for this?

[melvin-bot]

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

[wildan-m]

Proposal

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

When a report contains many expenses (40–50+) and the user bulk-edits them (for example toggling billable from the search bulk-edit page), the UI hangs and the browser tab can become unresponsive. There is also no visual feedback on the Save button while the edits are being submitted, so users have no signal that anything is happening and tend to keep clicking.

What is the root cause of that problem?

The hang is dominated by the bulk-edit loop firing an extra backend round-trip per selected expense, on top of the one UPDATE_MONEY_REQUEST call that is actually required.

Inside updateMultipleMoneyRequests, when a selected transaction does not already have a transactionThreadReportID cached locally (very common for expenses that were never opened, or were created offline, on large reports), the code calls createTransactionThreadReport(...) to make the optimistic thread exist so the MODIFIED_EXPENSE comment can be attached:

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

Lines 139 to 155 in ae75d99

	let didCreateThreadInThisIteration = false;
	if (!transactionThreadReportID && iouReport?.reportID) {
	const optimisticTransactionThread = createTransactionThreadReport({
	introSelected,
	currentUserLogin,
	currentUserAccountID,
	betas,
	iouReport,
	iouReportAction: reportAction,
	transaction,
	});
	if (optimisticTransactionThread?.reportID) {
	transactionThreadReportID = optimisticTransactionThread.reportID;
	transactionThread = optimisticTransactionThread;
	didCreateThreadInThisIteration = true;
	}
	}

The problem is that createTransactionThreadReport is not purely optimistic — it ends by calling openReport({...}):

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

Lines 2186 to 2214 in ae75d99

	const optimisticTransactionThreadReportID = generateReportID();
	const optimisticTransactionThread = buildTransactionThread(iouReportAction, reportToUse, currentUserAccountID, undefined, optimisticTransactionThreadReportID);
	const shouldAddPendingFields = transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD || iouReportAction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD;
	const participantAccountIDsForDetails = [currentUserAccountID];
	if (iouReportAction?.actorAccountID && iouReportAction.actorAccountID !== currentUserAccountID) {
	participantAccountIDsForDetails.push(iouReportAction.actorAccountID);
	}
	const participantLogins = PersonalDetailsUtils.getLoginsByAccountIDs(participantAccountIDsForDetails);
	const participants = buildParticipantInfoFromLogins(participantLogins);
	openReport({
	reportID: optimisticTransactionThreadReportID,
	introSelected,
	participants,
	// TODO: allPersonalDetails fallback should be removed in follow-up PRs https://github.com/Expensify/App/issues/73656
	personalDetails: personalDetails ?? allPersonalDetails,
	newReportObject: optimisticTransactionThread,
	parentReportActionID: iouReportAction?.reportActionID,
	transaction,
	transactionViolations,
	parentReportID: selfDMReportID,
	shouldAddPendingFields,
	optimisticSelfDMReport,
	currentUserLogin,
	currentUserAccountID,
	isSelfTourViewed,
	hasCompletedGuidedSetupFlow,
	betas,
	});
	return optimisticTransactionThread;

And openReport issues a real backend write through API.paginate(WRITE_COMMANDS.OPEN_REPORT, ...):

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

Lines 1439 to 1463 in ae75d99

	function openReport(params: OpenReportActionParams) {
	const {
	reportID,
	introSelected,
	reportActionID,
	participants = [],
	newReportObject,
	parentReportActionID,
	isFromDeepLink = false,
	personalDetails,
	isNewThread = false,
	transaction,
	transactionViolations,
	parentReportID,
	shouldAddPendingFields = true,
	optimisticSelfDMReport,
	currentUserLogin,
	currentUserAccountID,
	isSelfTourViewed,
	hasCompletedGuidedSetupFlow,
	betas,
	} = params;
	if (!reportID) {
	return;
	}

So a single Save click on N selected expenses becomes up to 2·N enqueued requests in the persistent queue:

• N UPDATE_MONEY_REQUEST writes (correct and necessary), and
• N OPEN_REPORT writes (unnecessary — we only needed to seed Onyx state, not ask the backend to open these threads).

On a report with 40–50 expenses this floods the persistent-queue serialization, the optimistic Onyx merges that fan out from each openReport (REPORT, REPORT_METADATA, REPORT_ACTIONS, RAM_ONLY_REPORT_LOADING_STATE, plus subscriber re-renders), and the JS thread on the main bundle. That is what the user perceives as the tab hanging.

Separately, the Save button in SearchEditMultiplePage calls updateMultipleMoneyRequests synchronously inside save and then immediately dismisses the RHP. The button itself has no loading state — Button supports isLoading but it is not used here:

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Lines 127 to 188 in ae75d99

	const save = () => {
	if (!draftTransaction) {
	return;
	}
	const changes: TransactionChanges = {};
	if (draftTransaction.amount !== undefined) {
	changes.amount = draftTransaction.amount;
	}
	if (draftTransaction.merchant) {
	changes.merchant = draftTransaction.merchant;
	}
	if (draftTransaction.comment?.comment) {
	changes.comment = draftTransaction.comment.comment;
	}
	if (draftTransaction.created) {
	changes.created = draftTransaction.created;
	}
	if (draftTransaction.category) {
	changes.category = draftTransaction.category;
	}
	if (draftTransaction.tag) {
	changes.tag = draftTransaction.tag;
	}
	if (draftTransaction.taxCode) {
	changes.taxCode = draftTransaction.taxCode;
	}
	if (typeof draftTransaction.billable === 'boolean') {
	changes.billable = draftTransaction.billable;
	}
	if (typeof draftTransaction.reimbursable === 'boolean') {
	changes.reimbursable = draftTransaction.reimbursable;
	}
	if (Object.keys(changes).length === 0) {
	Navigation.dismissToPreviousRHP();
	return;
	}
	updateMultipleMoneyRequests({
	transactionIDs: selectedTransactionIDs,
	changes,
	policy,
	reports: mergedReports,
	transactions: mergedTransactions,
	reportActions: mergedReportActions,
	policyCategories: allPolicyCategories,
	policyTags: allPolicyTags,
	hash: currentSearchHash,
	allPolicies: policies,
	introSelected,
	betas,
	currentUserAccountID,
	currentUserLogin: currentUserLogin ?? '',
	});
	// Bulk edit can start from report (ID-based selection) or search (map-based selection),
	// so clear both stores to keep deselection behavior consistent.
	clearSelectedTransactions(true);
	clearSelectedTransactions();
	Navigation.dismissToPreviousRHP();
	};

So during the long synchronous loop the user sees a normal, idle-looking Save button and keeps tapping it, which compounds the queue pressure.

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

Two changes, matching the two symptoms.

1. Stop firing OpenReport from the bulk-edit path.

   In src/libs/actions/IOU/BulkEdit.ts, the branch at lines 139–155 that builds an optimistic transaction thread for expenses missing one should no longer go through createTransactionThreadReport (which calls openReport). The optimistic state it needs — the thread Report object so the MODIFIED_EXPENSE action has a place to land — can be produced purely from local data. Concretely:

   • Build the optimistic thread inline using buildTransactionThread(iouReportAction, iouReport, currentUserAccountID, undefined, generatedReportID) (already used inside createTransactionThreadReport).
   • Push the matching optimistic Onyx merges directly into the iteration's optimisticData / successData / failureData arrays the loop is already constructing for API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST, ...). These merges are: REPORT for the new thread (newly created), REPORT_METADATA (set isLoadingInitialReportActions=false, etc., to match what openReport would have written for a fresh thread), and the same backfilled CREATED action the code already adds on lines 462–469.
   • Remove the call to createTransactionThreadReport from this hot loop entirely.

   Net effect: one persistent-queue write per transaction (the UPDATE_MONEY_REQUEST itself) instead of two, and the local Onyx state stays exactly as the user expects — the optimistic MODIFIED_EXPENSE action is still visible immediately when they open the transaction thread, including offline. The backend already creates the transaction thread when it processes UPDATE_MONEY_REQUEST against a thread it has never seen, so no functional regression: the next time the user navigates into that expense and openReport is fired naturally by ReportScreen, server data converges.

2. Show a loading spinner on the Save button while the edits are processing.

   In src/pages/Search/SearchEditMultiplePage.tsx, the save callback should:

   • Set a local isSaving state to true immediately.
   • Defer the actual updateMultipleMoneyRequests call into InteractionManager.runAfterInteractions (or requestAnimationFrame) so the spinner has a chance to paint before the synchronous loop blocks the JS thread.
   • After the loop returns, clear isSaving and proceed with the existing clearSelectedTransactions + Navigation.dismissToPreviousRHP calls.
   • Wire isSaving into the Button's isLoading prop and also isDisabled so repeated taps no-op.

   This addresses the "keep clicking" symptom and gives the user immediate feedback that their action was accepted, even before the (now-halved) queue finishes draining.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90707-bulk-edit-skip-open-report?expand=1

What alternative solutions did you explore? (Optional)

For symptom 1, an alternative is to extract an "optimistic-only" mode into createTransactionThreadReport / openReport via an explicit flag and have BulkEdit pass it. That works but expands the API of two already-overloaded functions; inlining the optimistic-thread build at the single bulk-edit caller keeps the surface area smaller and the contract for openReport unchanged (it always means "go ask the server").

For symptom 2, deferring with requestIdleCallback was also considered, but it is unavailable on React Native and behind a feature flag in some web environments, so InteractionManager.runAfterInteractions is the portable choice that's already used elsewhere in the codebase.

[melvin-bot]

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