Expense - "Review duplicates" button is unresponsive on expenses report.

[mitarachim]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.45-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome / Windows 10 - Chrome
App Component: Money Requests

Action Performed:

1. Open the Expensify app.
2. Open any workspace chat.
3. Submit two similar expenses.
4. Open the expenses report.
5. Tap on "Review Duplicates" on top of the report.
6. Note that no action is triggered with this action.

Expected Result:

When tapping on "Review Duplicates" on expenses report, the user should be able to begin the process to resolve the duplicates.

Actual Result:

"Review Duplicates" button is unresponsive on expenses report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6830331_1747178525907.Resolve.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @lydiabarclay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @mollfpr (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[mollfpr]

This is a regression from #60292

cc @VickyStash @hungvu193

[francoisl]

@mollfpr let's just go for a revert unless there's a super obvious and trivial fix. There are too many deploy blockers at the moment, and working on a fix might introduce another issue that will delay the deploy even more.

[hungvu193]

I couldn't reproduce this one on staging

Screen.Recording.2025-05-14.at.11.05.32.mov

[hungvu193]

Ok I can reproduce with brandnew workspace and expenses.
getThreadReportIDsForTransactions returns null because the action doesn't have childReportID.

[VickyStash]

Hi there 👋 I'm checking the issue!

[VickyStash]

I was able to reproduce the issue!
It looks like the Add review duplicates to report level PR updates were merged not so long ago - just a week has passed, so that's why I guess it was missed in this PR.

The updated logic works this way:

1. When the user presses the Review duplicates button on the report level, the app tries to get getFirstDuplicateThreadID to then go through the review duplicates flow from it.
2. The review duplicate flow has a lot of possible navigation flows: see here , and to every route threadReportID is passed. Besides that on the Confirmation page the threadReport data is used to display information.

So ideally, we need to find a way to create a transaction thread for the first transaction in the moment when user tries to review duplicates from the expense report.
As another option, we can try to create it optimistically and set it to Onyx and only later pass it to BE during mergeDuplicates call. But I guess with this approach, we can have some side effects in other flows.
cc @iwiznia

Anyway, it doesn't look like a super easy fix.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[mollfpr]

Agree with @francoisl! I'm going to revert the offending PR #60292 🙏

[luacmartins]

Thanks for handling this one

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[luacmartins]

This is fixed on staging

[iwiznia]

So ideally, we need to find a way to create a transaction thread for the first transaction in the moment when user tries to review duplicates from the expense report.

Can we do that by calling OpenReport?

[VickyStash]

Can we do that by calling OpenReport?

Yeah, that's what I'm going to try tomorrow!

[luacmartins]

@VickyStash this is how we handle it in Search for transactions that didn't have a reportID. It might help you

App/src/components/Search/index.tsx

Lines 400 to 412 in f65da19

	if (isTransactionItem && reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	reportID = generateReportID();
	updateSearchResultsWithTransactionThreadReportID(hash, item.transactionID, reportID);
	Navigation.navigate(
	ROUTES.SEARCH_REPORT.getRoute({
	reportID,
	backTo,
	moneyRequestReportActionID: item.moneyRequestReportActionID,
	transactionID: item.transactionID,
	}),
	);
	return;
	}

[lydiabarclay]

@luacmartins - should I create an Upwork job manually here? I see folks have already been assigned.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[mollfpr]

should I create an Upwork job manually here? I see folks have already been assigned.

@lydiabarclay Nope. This is a regression, so no payment is due.