[Due for payment 2026-08-27] [$250] Duplicates-Not here RHP opens when Admin clicks "Review duplicates" offline

[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.47-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96607
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 15 iOS 26.5.2, MacBook Air 26.5.2
App Component: Money Requests

Action Performed:

1. Log in as an admin, create a Collect workspace, and invite a member
2. As the member, go to the workspace chat
3. Click "+" button near the composer - Create expense - Manual - create an expense
4. Open the expense, click More - Add expense - Create expense - create an expense with the same amount, merchant, date, currency, and category
5. As the admin, open the workspace chat
6. Go offline
7. Open the expense report
8. Click "Resolve duplicates" button

Expected Result:

"Not here" RHP is not shown after clicking "Review duplicates", Admin can proceed with the flow offline

Actual Result:

"Not here" RHP opens when Admin clicks "Review duplicates" in the Member's report offline

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7222988_1785530702167.New_Not_here.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7222988

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022083315987969348982
• Upwork Job ID: 2083315987969348982
• Last Price Increase: 2026-08-03

Issue Owner

Current Issue Owner: @mallenexpensify

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

[MelvinBot]

Proposal

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

When an admin/manager is offline and clicks Review duplicates on another member's expense report, the duplicate-review RHP renders the "Not here" (FullPageNotFoundView) page instead of opening the duplicate resolution flow. Online it works. Expected: the flow should open offline.

What is the root cause of that problem?

The duplicate-review page (DynamicReviewPage.tsx) resolves the transaction it should show from the parent expense report's IOU report action, read straight from local Onyx:

const reportAction = getReportAction(report?.parentReportID, report?.parentReportActionID);
const transactionID = getLinkedTransactionID(reportAction);

For another member's report that was only surfaced via a report/search snapshot, that parent action is populated by an OpenReport / GetDuplicateTransactionDetails API call — which cannot run while offline. So reportAction is undefined → transactionID is empty.

Normally an empty transactionID just keeps the page in a loading skeleton while the fetch completes. But offline, hasLoadedReportActions() returns true unconditionally (... || isOffline). That collapses the loading state and, via getParentReportActionDeletionStatus (isParentActionMissingAfterLoad → wasParentActionDeleted = true), makes a not-yet-loaded action look deleted. The net effect at DynamicReviewPage.tsx:110-116:

const isLoadingPage = ... ; // forced false offline
const shouldShowNotFound = !isNavigatingBackToDeletedReview && (wasTransactionDeleted || (!isLoadingPage && !transactionID));

Both branches (wasTransactionDeleted and !isLoadingPage && !transactionID) become true offline → "Not here" is shown. The || isOffline short-circuit was meant to avoid an infinite skeleton after an offline delete, but it's too broad: it can't tell "the action was deleted offline" apart from "the action was simply never fetched," so the latter is misclassified as deleted.

Data flow

1. Admin (offline) opens a member's expense report; the Review duplicates button shows because the DUPLICATED_TRANSACTION violation is already in Onyx from the snapshot — independent of the destination page's data needs.
2. Button navigates to the duplicate-review route with the transaction-thread reportID.
3. DynamicReviewPage needs the parent IOU action to derive transactionID; it isn't in local Onyx for that member's report.
4. openReport() / getDuplicateTransactionDetails() are queued but can't run offline.
5. isOffline forces hasLoadedReportActions() = true → isLoadingPage = false and wasParentActionDeleted = true → shouldShowNotFound = true.

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

Distinguish "parent action deleted offline" from "parent action never loaded offline" so only a genuine deletion yields "Not here":

• In getParentReportActionDeletionStatus, don't let the offline branch of hasLoadedReportActions drive isParentActionMissingAfterLoad. A missing parent action should only count as "deleted" when we actually loaded actions (hasOnceLoadedReportActions/isLoadingInitialReportActions === false), not merely because we're offline. Keep the offline short-circuit for the thread-deleted-offline back-navigation case it was added for.
• Net result: offline, when the parent action was never fetched, isLoadingPage stays true and the page shows the skeleton (and recovers when back online) instead of a false "Not here."

Whether the flow can then fully complete offline depends on the duplicate transactions themselves being present in Onyx; where they are, the review should render, matching the expected result.

What alternative solutions did you explore?

• Gate the Review duplicates button's visibility on the parent action being loaded — rejected: the expected result is that the admin can proceed offline, so hiding the entry point is worse UX and doesn't fix cases where data is available.

---

⚠️ Confidence & caveats

Confidence: medium. The mechanism is verified directly against current main (f202ade). Two caveats: (1) the reported version (9.4.47-5) predates today's heavily offline-instrumented DynamicReviewPage, so the exact lines differed then, but the "missing-offline-data → not found" root cause is the same; (2) the single unverified assumption is that the parent IOU action is genuinely absent from local Onyx for another member's report opened offline — confirming that with an offline Onyx-state inspection would raise this to high.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97610) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[bernhardoj]

@trjExpensify hmm, I'm not sure what the expected behavior should be here. The "review duplicates" page shows not found because the transaction thread isn't loaded yet (and it can't be loaded while offline). Should we hide the "Review duplicates" button?

[mukhrr]

@bernhardoj I think we should let the page resolve the transaction from cached data when the thread report is unavailable

[bernhardoj]

A transaction doesn't have parentReportActionID, policyID, etc.

[mukhrr]

I mean that transaction's expense report, not from the transaction,

[bernhardoj]

Ah, that's my initial thought too, but I don't think that's enough. We use a lot of properties from the transaction thread report that are not replaceable with the expense report, including in DynamicConfirmationPage, MoneyRequestView, etc.

[mukhrr]

hmm you seem to be right.. what about seeding the thread report itself instead of replacing the thread report's fields. The button already knows the thread ID from the IOU action's childReportID, we just hold no copy of it now. buildTransactionThread already takes an explicit reportID and fills parentReportID, parentReportActionID and policyID, so I'd make createTransactionThreadReport accept a known ID and the button passes it when offline and uncached. Since it's the server's own ID it merges on reconnect instead of creating a second thread.