[Due for payment 2026-06-03] [$250] Expense - Duplicate report with rejected expenses

[lanitochka17]

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: v9.3.60-14
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/27754595/test-cases/65943370
Email or phone of affected tester (no customers): agexptest+wt170426@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Money Requests

Action Performed:

Preconditions:
Have a workspace with Delayed Submissions and Approvals enabled.
Have an expense report with 3 expenses from a submitter user.

1. Open the Expensify app
2. Log in as the workspace admin
3. Go to the submitter's workspace chat
4. Go to the expense report
5. Reject 2 of those 3 expenses
6. Go back to the submitter's workspace chat

Expected Result:

Only one report with rejected expenses is created.

Actual Result:

Two identical reports with rejected expenses are created.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7132451_1776448998321.dupe_report.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mananjadhav

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022045238445165917906
• Upwork Job ID: 2045238445165917906
• Last Price Increase: 2026-05-01

[MelvinBot]

Proposal

What is the root cause of that problem?

When rejecting 2 of 3 expenses from a report with delayed submission enabled, rejectMoneyRequestsOnSearch (Search.ts:1244-1249) generates a single sharedRejectedToReportID and calls rejectMoneyRequest in a synchronous for-loop — one call per expense.

Each call runs prepareRejectMoneyRequestData, which looks up allReports for an existingOpenReport to reuse. However, API.write() applies Onyx optimistic data asynchronously, so the second call still reads stale allReports and doesn't see the optimistic report created by the first call. Both calls fall into the "create new report" branch.

While sharedRejectedToReportID ensures both calls target the same report ID, each call independently creates its own REPORTPREVIEW action and MERGEs it into the workspace chat's report actions. Two REPORTPREVIEW actions in the same workspace chat render as two separate report entries in the UI — the duplicate reports.

Additionally, the second Onyx.METHOD.SET on the same report key overwrites the first, so the report's parentReportActionID only points to the second REPORTPREVIEW.

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

In prepareRejectMoneyRequestData, when sharedRejectedToReportID is provided and no existingOpenReport is found, only the first call (the one that creates the report) should generate the REPORTPREVIEW action and the Onyx.METHOD.SET for the new report. Subsequent calls using the same sharedRejectedToReportID should skip report creation and REPORTPREVIEW generation, and instead only add their transaction to the already-created destination report (similar to the existingOpenReport branch at line 358).

Concretely: track whether the report for sharedRejectedToReportID has already been optimistically created (e.g., via a shared mutable flag or by building the optimistic report once in rejectMoneyRequestsOnSearch and passing it down). When the flag is set, the second call should take the existingOpenReport path — reuse the report and skip REPORTPREVIEW + SET creation.

What alternative solutions did you explore? (Optional)

An alternative is to batch all transactions into a single API.write call (similar to rejectMoneyRequestInBulk), consolidating optimistic data so only one REPORTPREVIEW is ever created. This is cleaner but is a larger change — the current per-transaction loop exists because rejectMoneyRequestInBulk only handles the "all expenses selected" case with different server-side semantics.

Investigation details

Key code path:

1. rejectMoneyRequestsOnSearch — generates sharedRejectedToReportID, loops calling rejectMoneyRequest per transaction
2. prepareRejectMoneyRequestData — reads allReports (stale on second iteration)
3. existingOpenReport lookup — fails to find optimistic report from first call
4. New report + REPORTPREVIEW created — happens twice, creating duplicate UI entries

Why sharedRejectedToReportID doesn't fully prevent duplication: It ensures both calls use the same destination reportID, but each call still independently generates its own buildOptimisticReportPreview action (line 466) and SETs the report data (line 481). The sharedRejectedToReportID mechanism was designed to share the ID but not to coordinate which call "owns" the report creation.

Confidence: High — the async Onyx update timing and duplicate REPORTPREVIEW generation are clearly visible in the code path.

---

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 - @mananjadhav (External)

[melvin-bot]

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

[github-actions]

⚠️ @aswin-s Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[aswin-s]

Proposal

What is the root cause of that problem?

When the admin selects 2 of 3 expenses and bulk-rejects from the expense report view (via SelectionToolbar), the app navigates to SearchRejectReasonPage.tsx, which calls rejectMoneyRequestsOnSearch in src/libs/actions/Search.ts. Because fewer than all expenses are selected, the code at lines 1244–1249 runs a synchronous for loop, calling rejectMoneyRequest() once per selected transaction with a shared sharedRejectedToReportID.

The problem is that both iterations of the loop run in the same JavaScript execution frame. The allReports module-level variable in src/libs/actions/IOU/index.ts is updated via an Onyx.connect() callback, which fires asynchronously — after the current call stack completes. So when the second rejectMoneyRequest() call reads getAllReports() and checks for existingOpenReport (lines 349–356 of RejectMoneyRequest.ts), the optimistically created report from the first call is not yet reflected in allReports. Both calls fall through to the else branch at line 433 and both enter the "create new report" path with the same rejectedToReportID.

Each call issues its own API.write(REJECT_MONEY_REQUEST, ...) with a unique reportPreviewReportActionID (line 860) and unique createdIOUReportActionID/expenseCreatedReportActionID. The server interprets each as a separate "create expense report + add preview to workspace chat" operation, resulting in two distinct reports. Additionally, the second call's Onyx.METHOD.SET (line 481) destructively overwrites the first call's optimistic report data, so local state only reflects the second transaction.

App/src/libs/actions/Search.ts

Lines 1244 to 1249 in c05060c

	} else {
	// Share a single destination ID across all rejections from the same source report
	const sharedRejectedToReportID = generateReportID();
	for (const transactionID of selectedTransactionIDs) {
	rejectMoneyRequest(transactionID, reportID, comment, policy, currentUserAccountIDParam, betas, {sharedRejectedToReportID});
	}

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

1. src/libs/actions/Search.ts — in the for loop (lines 1247–1249), track iteration index and pass a new isFirstInBatch: boolean flag to each rejectMoneyRequest call: true only for the first iteration, false for all subsequent ones.

2. src/libs/actions/IOU/RejectMoneyRequest.ts — add isFirstInBatch?: boolean to the options type on the prepareRejectMoneyRequestData and rejectMoneyRequest signatures (lines 109 and 878).

3. src/libs/actions/IOU/RejectMoneyRequest.ts — in the else branch at line 433, when sharedRejectedToReportID is provided and isFirstInBatch === false, skip buildOptimisticExpenseReport, skip creating a new reportPreviewAction (line 466), use Onyx.METHOD.MERGE instead of SET for the report key (line 481), and omit reportPreviewReportActionID/expenseCreatedReportActionID from the API parameters. The second and later calls should only carry their own transactionID, iouAction, and childReportID update — effectively the same "add to existing report" path as lines 376–432 but targeting the shared destination reportID.

This ensures only the first API call creates the report and the preview in the workspace chat; subsequent calls in the same batch simply add their transaction to it.

What alternative solutions did you explore? (Optional)

An alternative is to introduce a new server endpoint that accepts an array of transaction IDs and rejects them atomically, eliminating the loop entirely. This is more robust but requires a backend change and is a larger scope. The chosen approach is a targeted client-side fix that works within the existing REJECT_MONEY_REQUEST endpoint by ensuring only one "create report" payload is sent per batch.

Edge cases the fix must handle:

• Offline state: API.write() queues requests; the fix must ensure the merged optimistic data for the shared report is consistent so rollback on failure reverts both transactions correctly.
• Single-transaction rejection (no sharedRejectedToReportID supplied, e.g., from RejectReasonPage.tsx): the new isFirstInBatch flag defaults to true/undefined, leaving that path unchanged.

[Yatin-Bhatti]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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

[nabi-ebrahimi]

Proposal

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

Expense - Duplicate report with rejected expenses

What is the root cause of that problem?

In the search rejection flow, we generate one shared rejectedToReportID, but we still call rejectMoneyRequest() once per selected transaction inside a synchronous loop:

App/src/libs/actions/Search.ts

Lines 1242 to 1248 in 03023c1

	if (isPolicyDelayedSubmissionEnabled && areAllExpensesSelected) {
	rejectMoneyRequestInBulk(reportID, comment, policy, selectedTransactionIDs, currentUserAccountIDParam, betas, hash);
	} else {
	// Share a single destination ID across all rejections from the same source report
	const sharedRejectedToReportID = generateReportID();
	for (const transactionID of selectedTransactionIDs) {
	rejectMoneyRequest(transactionID, reportID, comment, policy, currentUserAccountIDParam, betas, {sharedRejectedToReportID});

Then, inside prepareRejectMoneyRequestData(), each call looks for an already-open destination report by reading allReports:

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

Lines 349 to 356 in 03023c1

	const existingOpenReport = Object.values(allReports ?? {}).find(
	(r) =>
	r?.reportID !== reportID &&
	r?.chatReportID === report.chatReportID &&
	r?.type === CONST.REPORT.TYPE.EXPENSE &&
	isOpenReport(r) &&
	r?.ownerAccountID === report.ownerAccountID,
	);

If no open report is found, the code falls into the "create new report" branch, where it creates a new optimistic expense report, a new REPORTPREVIEW action, and the related optimistic data for the destination report:

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

Lines 433 to 513 in 03023c1

	} else {
	// When no existing open report is found, use the sharedRejectedToReportID
	// so multiple sequential rejections land in the same destination report
	// Fallback to generating a fresh ID if not provided
	rejectedToReportID = rejectedToReportID ?? generateReportID();
	// Pass transaction for formula computation (e.g., {report:startdate})
	const reportTransactions: Record<string, OnyxTypes.Transaction> = {[transaction.transactionID]: transaction};
	const newExpenseReport = buildOptimisticExpenseReport({
	chatReportID: report.chatReportID,
	policyID: report?.policyID,
	payeeAccountID: report?.ownerAccountID ?? CONST.DEFAULT_NUMBER_ID,
	total: transactionAmount,
	currency: getCurrency(transaction),
	nonReimbursableTotal: transactionAmount,
	optimisticIOUReportID: rejectedToReportID,
	reportTransactions,
	betas,
	});
	const [, createdActionForExpenseReport, iouAction] = buildOptimisticMoneyRequestEntities({
	iouReport: newExpenseReport,
	type: CONST.IOU.REPORT_ACTION_TYPE.CREATE,
	amount: transactionAmount,
	currency: getCurrency(transaction),
	comment: parsedComment,
	payeeEmail: deprecatedCurrentUserEmail,
	participants: [{accountID: report?.ownerAccountID}],
	transactionID: transaction.transactionID,
	existingTransactionThreadReportID: childReportID,
	shouldGenerateTransactionThreadReport: false,
	});
	reportPreviewAction = buildOptimisticReportPreview(policyExpenseChat, newExpenseReport, undefined, transaction, undefined);
	movedTransactionAction = buildOptimisticMovedTransactionAction(childReportID, newExpenseReport.reportID);
	createdIOUReportActionID = iouAction.reportActionID;
	expenseMovedReportActionID = movedTransactionAction.reportActionID;
	expenseCreatedReportActionID = createdActionForExpenseReport.reportActionID;
	newExpenseReport.parentReportActionID = reportPreviewAction.reportActionID;
	optimisticData.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${policyExpenseChat?.reportID}`,
	value: {
	lastVisibleActionCreated: reportPreviewAction.created,
	},
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${rejectedToReportID}`,
	value: {
	...newExpenseReport,
	pendingFields: {createReport: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD},
	},
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${rejectedToReportID}`,
	value: {
	isOptimisticReport: true,
	hasOnceLoadedReportActions: true,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${rejectedToReportID}`,
	value: {[createdActionForExpenseReport.reportActionID]: createdActionForExpenseReport, [iouAction.reportActionID]: iouAction},
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${rejectedToReportID}`,
	value: {
	parentReportID: report?.chatReportID,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${policyExpenseChat?.reportID}`,
	value: {
	[reportPreviewAction.reportActionID]: reportPreviewAction,
	},

The issue is that both rejections run in the same JS turn, while the optimistic Onyx update from the first rejection is not yet available through allReports when the second rejection executes. As a result, the second call does not see the optimistic destination report created by the first call, falls into the same "create new report" branch, and creates a second REPORTPREVIEW entry for the same shared destination.

So the bug is not that sharedRejectedToReportID is missing. The bug is that the second iteration has no synchronous access to the optimistic rejected report object created by the first iteration.

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

We should keep the fix local to the existing sequential reject flow and pass the optimistic rejected report forward in memory during the loop, instead of waiting for allReports to catch up.

1. Reuse one shared options object across the whole rejection loop

Apply this change at:

Search.ts#L1245-L1248

- const sharedRejectedToReportID = generateReportID();
+ const sharedRejectOptions = {sharedRejectedToReportID: generateReportID()};
  for (const transactionID of selectedTransactionIDs) {
-     rejectMoneyRequest(transactionID, reportID, comment, policy, currentUserAccountIDParam, betas, {sharedRejectedToReportID});
+     rejectMoneyRequest(transactionID, reportID, comment, policy, currentUserAccountIDParam, betas, sharedRejectOptions);
  }

• This keeps one mutable object alive for the whole batch. The first rejection can store the optimistic rejected report on it, and later rejections can reuse that exact object immediately.

2. Teach rejectMoneyRequest() to prefer the in-memory optimistic rejected report before reading allReports

Apply this change around:

RejectMoneyRequest.ts#L349-L356

+ type RejectMoneyRequestOptions = {
+     sharedRejectedToReportID?: string;
+     existingRejectedReport?: OnyxEntry<OnyxTypes.Report>;
+ };

- const existingOpenReport = Object.values(allReports ?? {}).find(...)
+ const existingOpenReport = options?.existingRejectedReport ?? Object.values(allReports ?? {}).find(...)

• If the first iteration already created an optimistic rejected report, the second iteration should use that object directly instead of relying on allReports, which is still stale at that moment.

3. Store the optimistic rejected report into the shared options object as soon as it is known

Apply this change in both branches that determine the destination rejected report:

• Existing-open-report branch:
  RejectMoneyRequest.ts#L358-L398
• New-report branch:
  RejectMoneyRequest.ts#L442-L513

  movedToReport = {
      ...existingOpenReport,
      total: (existingOpenReport?.total ?? 0) - transactionAmount,
  };
+ if (options) {
+     options.existingRejectedReport = movedToReport;
+ }

  const newExpenseReport = buildOptimisticExpenseReport({...});
  newExpenseReport.parentReportActionID = reportPreviewAction.reportActionID;
+ if (options) {
+     options.existingRejectedReport = newExpenseReport;
+ }

• The first rejection writes the optimistic destination report into the shared options object immediately. The second rejection then reuses it and takes the existing-report path, which prevents another REPORTPREVIEW from being created.

Why this approach is the best fit

This is a small, low-risk fix because it:

• keeps the current API contract and reject flow intact
• only changes the delayed-submission multi-reject path
• solves the stale-state race at the point where it happens
• follows an existing codebase pattern where optimistic report objects are passed forward locally during sequential operations

What alternative solutions did you explore? (Optional)

Demo

88236.mov