[$250] LHN - LHN displays more items than original account after Onyx import

[nlemma]

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: 9.3.55-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: https://github.com/Expensify/Expensify/issues/455022
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11
App Component: Other

Action Performed:

Preconditions: Logged in to any account

Steps:

1. Go to Settings -> Troubleshoot
2. Export Onyx state
3. Open a new browser / incognito window and log into a brand new account
4. Go to Settings -> Troubleshoot
5. Press Import Onyx state and select the exported file
6. Wait until the file loads
7. Compare the LHN numbers between the original account and the imported Onyx

Expected Result:

the LHN have an equally large number of items comparing to the original account

Actual Result:

the LHN of the new account after importing onyx have a larger number of items comparing to the original account

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7120671_1775216270745.1773729451748_onyx_state.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abbasifaizan70

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042283147103130905
• Upwork Job ID: 2042283147103130905
• Last Price Increase: 2026-04-09
• Automatic offers:
• thelullabyy | Reviewer | 111136400

[MelvinBot]

Proposal

What is the root cause of that problem?

During Onyx state import, collections are set in parallel via Promise.all in ImportOnyxState.ts:11-16. This creates a race condition where report_ data arrives and triggers LHN rendering before reportActions_ data is available.

The LHN filtering function isOneTransactionThread relies on a module-level allReportActions variable that uses waitForCollectionCallback: true — meaning it only updates when the entire reportActions_ collection is ready. During the window between report_ being set and reportActions_ arriving, transaction threads that should be hidden pass the filter and appear as extra items in the LHN.

Additionally, the session (containing the correct accountID) is set after all collections via multiSet in ImportOnyxStateUtils.ts:84-86, so getReportNotificationPreference temporarily uses Account B's accountID to look up participants in Account A's reports.

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

The import in ImportOnyxStateUtils.ts should set the session/regular keys before or simultaneously with collections, and force a full LHN rebuild after all import operations complete. Specifically:

1. In importState(), call importOnyxRegularState (which sets the session with the correct accountID) before importOnyxCollectionState, so that deprecatedCurrentUserAccountID is correct when report subscribers fire.
2. After all import operations complete, invalidate the useSidebarOrderedReports incremental cache (e.g., by toggling a key or clearing currentReportsToDisplay) to force a full re-evaluation of which reports should display, ensuring the final state reflects correct filtering with all data present.

What alternative solutions did you explore? (Optional)

• Sequencing setCollection calls (setting reportActions_ before report_) would also fix the race, but would significantly slow down import since collections would no longer load in parallel.
• Wrapping all setCollection calls in Onyx.update batched operations could prevent intermediate renders, but would require changes to how Onyx processes bulk imports.

Investigation details

Import flow:

1. Onyx.clear(KEYS_TO_PRESERVE) — clears data but preserves Account B's SESSION
2. importOnyxCollectionState — Promise.all on all setCollection calls in parallel
3. importOnyxRegularState — Onyx.multiSet sets regular keys including Account A's SESSION

Key code locations:

• Import handler: src/components/ImportOnyxState/index.tsx
• Import logic: src/libs/ImportOnyxStateUtils.ts
• Onyx set operations: src/libs/actions/ImportOnyxState.ts
• LHN ordering with incremental cache: src/hooks/useSidebarOrderedReports.tsx
• shouldDisplayReportInLHN: src/libs/SidebarUtils.ts:258
• isOneTransactionThread depending on allReportActions: src/libs/ReportUtils.ts:2651
• allReportActions connected with waitForCollectionCallback: src/libs/ReportUtils.ts:1180

---

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

[melvin-bot]

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

[twilight2294]

Proposal

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

After importing another account's Onyx state, the LHN shows extra items (like one-transaction threads) that don't appear on the original account.

What is the root cause of that problem?

importOnyxCollectionState() in ImportOnyxState writes all collections in parallel via Promise.all. Each Onyx.setCollection independently triggers subscriber notifications. When report_ settles before reportActions_, the LHN re-renders with reports present but no report actions — so isOneTransactionThread() in ReportUtils returns false (no actions to inspect), and those threads pass through shouldDisplayReportInLHN() as visible items instead of being filtered out.

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

Replace the parallel setCollection calls with a single Onyx.multiSet in ImportOnyxState:

function importOnyxCollectionState(collectionsMap: Map<keyof OnyxCollectionValuesMapping, CollectionDataSet<OnyxCollectionKey>>): Promise<void> {
    const allEntries: Record<string, unknown> = {};
    for (const [, items] of collectionsMap.entries()) {
        if (items) {
            Object.assign(allEntries, items);
        }
    }
    return Object.keys(allEntries).length > 0
        ? Onyx.multiSet(allEntries as Partial<OnyxValues>)
        : Promise.resolve();
}

multiSet writes all keys atomically and fires subscribers only once after all data is present. When the LHN re-renders, reportActions_ is already available alongside report_, so isOneTransactionThread() correctly identifies and filters one-transaction threads.

What alternative solutions did you explore? (Optional)

This differs from MelvinBot's proposal in two ways: (1) MelvinBot suggests reordering session before collections + invalidating the LHN cache after import — that's two changes across two files working around the race condition. This fix eliminates the race condition at its source with a single function change, so no cache invalidation is needed. (2) MelvinBot's reordering approach still leaves collections writing in parallel, meaning the report_ vs reportActions_ race persists — the session fix only addresses the accountID timing, not the missing report actions that cause isOneTransactionThread() to misfire.

[Ltbltbltbltb]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[wildan-m]

Proposal

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

After exporting Onyx state from Account A and importing it into a brand-new Account B via Settings → Troubleshoot → Import Onyx state, the LHN of the new account ends up displaying more items than the original Account A's LHN (extra transaction-thread entries appear that should be hidden behind their parent reports).

What is the root cause of that problem?

The import pipeline in ImportOnyxStateUtils.ts pushes data into Onyx in an order that lets the LHN re-render against partially loaded state, and the LHN filtering code then relies on module-level caches in ReportUtils.ts that do not get invalidated on Onyx.clear.

Step 1 — import order. In importState() the pipeline is clear → importOnyxCollectionState → importOnyxRegularState:

App/src/libs/ImportOnyxStateUtils.ts

Lines 84 to 86 in 20e2b89

	return clearOnyxStateBeforeImport()
	.then(() => importOnyxCollectionState(collectionsMap))
	.then(() => importOnyxRegularState(regularState));

importOnyxRegularState contains the imported SESSION key, so Account A's accountID is applied last. Meanwhile importOnyxCollectionState fires every Onyx.setCollection call in parallel via Promise.all:

App/src/libs/actions/ImportOnyxState.ts

Lines 11 to 16 in 20e2b89

	function importOnyxCollectionState(collectionsMap: Map<keyof OnyxCollectionValuesMapping, CollectionDataSet<OnyxCollectionKey>>): Promise<void[]> {
	const collectionPromises = Array.from(collectionsMap.entries()).map(([baseKey, items]) => {
	return items ? Onyx.setCollection(baseKey, items) : Promise.resolve();
	});
	return Promise.all(collectionPromises);
	}

The order in which subscribers see these collections is non-deterministic, and REPORT frequently wins the race.

Step 2 — stale module-level caches in ReportUtils. When Onyx.clear runs, subscribers with waitForCollectionCallback: true are called with null, but several of the module-level caches short-circuit on a falsy value and keep Account B's data:

App/src/libs/ReportUtils.ts

Lines 1181 to 1190 in 20e2b89

	Onyx.connect({
	key: ONYXKEYS.COLLECTION.REPORT_ACTIONS,
	waitForCollectionCallback: true,
	callback: (actions) => {
	if (!actions) {
	return;
	}
	allReportActions = actions;
	},
	});

So after Onyx.clear, allReportActions still points to Account B's old actions. The same pattern exists for deprecatedAllTransactions, allPolicies, and several other caches in the same file.

Step 3 — LHN rebuilds against an inconsistent snapshot. Once setCollection(REPORT, ...) lands, useSidebarOrderedReports re-computes the LHN. For each of Account A's reports it calls shouldDisplayReportInLHN → isOneTransactionThread:

App/src/libs/ReportUtils.ts

Lines 2651 to 2661 in 20e2b89

	function isOneTransactionThread(report: OnyxEntry<Report>, parentReport: OnyxEntry<Report>, threadParentReportAction: OnyxEntry<ReportAction>, isOffline?: boolean) {
	if (!report || !parentReport) {
	return false;
	}
	const parentReportActions = allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReport?.reportID}`] ?? ([] as ReportAction[]);
	const chatReport = deprecatedAllReports?.[`${ONYXKEYS.COLLECTION.REPORT}${parentReport?.chatReportID}`];
	const transactionThreadReportID = getOneTransactionThreadReportID(parentReport, chatReport, parentReportActions, isOffline);
	return report?.reportID === transactionThreadReportID && !isSentMoneyReportAction(threadParentReportAction);
	}

That function reads allReportActions[REPORT_ACTIONS + parentReport.reportID], but allReportActions is still Account B's cache — it has no entries for Account A's report IDs. parentReportActions resolves to [], getOneTransactionThreadReportID returns undefined, and isOneTransactionThread returns false. The transaction-thread report, which should be hidden behind its parent expense report, is therefore not filtered out and is added to the LHN as an extra row. The same broken filter result is then written into the hook's incremental cache currentReportsToDisplay via setCurrentReportsToDisplay.

On top of that, because SESSION is imported last, deprecatedCurrentUserAccountID is still Account B's ID while Account A's reports are being evaluated, so participant-based checks (getReportNotificationPreference, isHiddenForCurrentUser, self-DM detection, etc.) also run with the wrong account during the race window.

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

Change importState() in src/libs/ImportOnyxStateUtils.ts so that the import pipeline guarantees a consistent world before the LHN (or any other screen) can re-render against a collection of reports:

1. Run importOnyxRegularState before importOnyxCollectionState, so that SESSION (and therefore deprecatedCurrentUserAccountID) is already Account A's by the time any collection subscriber fires.
2. Inside importOnyxCollectionState, replace the Promise.all with a sequential chain (e.g. .reduce((prev, next) => prev.then(next))) and order the collections so that ONYXKEYS.COLLECTION.REPORT is imported last. All of the collections that the LHN filtering implicitly depends on — REPORT_ACTIONS, REPORT_METADATA, REPORT_NAME_VALUE_PAIRS, TRANSACTION, TRANSACTION_VIOLATIONS, POLICY, and their siblings — should be set first.

With this ordering, by the time setCollection(REPORT, ...) lands and triggers the LHN to re-evaluate, every waitForCollectionCallback subscriber in ReportUtils.ts has already been updated with Account A's data, so isOneTransactionThread and all the other shouldDisplayReportInLHN checks see a consistent snapshot and correctly hide transaction threads behind their parent expense reports. No module-level cache has to be reset and no downstream cache in useSidebarOrderedReports has to be invalidated — the first render is already correct.

Separately (small, low-risk cleanup), the if (!actions) return guard at ReportUtils.ts:1185-1187 should let a cleared collection overwrite the module cache instead of silently keeping the previous account's actions, so that any future code path that clears Onyx without going through this importer does not hit the same class of bug. The same guard is duplicated in several siblings in ReportUtils.ts and in deprecatedAllReports/allPolicies/deprecatedAllTransactions — each of those if (!value) return early-returns should be replaced with an explicit reset of the cache variable.

What alternative solutions did you explore? (Optional)

• Batch everything via Onyx.update. Conceptually the cleanest — one atomic update, subscribers see a single consistent state. I rejected it because Onyx.update does not have a first-class "replace entire collection" operation equivalent to setCollection, so this would be a larger refactor of how the importer expresses collection replacement.
• Post-import LHN cache invalidation. Expose the hook's clearLHNCache and call it at the end of importState() so the LHN rebuilds from scratch after everything is loaded. This works for LHN specifically, but it's a symptom-level workaround: it leaves the module-level caches in ReportUtils.ts stale during the race, so any other screen or derived value that runs during the intermediate window still sees inconsistent data. I preferred fixing the ordering at the source so every downstream subscriber benefits.

---

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87517-import-onyx-lhn-race?expand=1

[github-actions]

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

[wildan-m]

Proposal updated — added compare branch with implementation.