[$250] Certain actions in LHN don't sync between tabs

[fabioh8010]

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.21-9
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @fabioh8010
Slack conversation (hyperlinked to channel name):

Action Performed:

Pre-requisites:

• Open two NewDot tabs with the same account logged in.

Sync report pinning in LHN

1. In Tab A, pin one report from LHN.
2. Switch to Tab B.

Sync draft message and LHN re-ordering

1. In Tab A, choose one report in the middle of LHN list, select and draft a message.
2. Switch to Tab B.

Sync marking report as unread in LHN

1. In Tab A, mark one report as unread.
2. Switch to Tab B.

Expected Result:

Sync report pinning in LHN / Sync draft message and LHN re-ordering / Sync marking report as unread in LHN

The actions should be synced to Tab B.

Actual Result:

Sync report pinning in LHN / Sync draft message and LHN re-ordering / Sync marking report as unread in LHN

The actions are not being synced to Tab B.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Screen.Recording.2026-06-29.at.14.14.28.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071588560589258611
• Upwork Job ID: 2071588560589258611
• Last Price Increase: 2026-06-29

Issue Owner

Current Issue Owner: @truph01

[fabioh8010]

This bug was originally discovered here. The bug happens in Onyx:

The collection key callbacks with waitForCollectionCallback: true are not notified during tab syncs, only collection key callbacks without waitForCollectionCallback: true (per-member mode) or regular/collection member keys.

I have an almost-working solution in #93436. This solution fixes the scenarios reported above but there are two more test scenarios we need to check:

Two tabs with the heavy pilot account

1. Refresh both Tabs and stay in Tab A.
2. Wait for around 30 seconds.
3. Assert the Tabs don't crash and work normally.

Clearing cache from heavy imported state

1. In Tab A, import a really heavy Onyx state.
2. Assert Tab B is also using the imported state.
3. Once it's done, Go to Account > Troubleshoot and click Clear cache and restart.
4. Wait until the process is done.
5. Assert Tab B is also restored to the normal state.

With the current PR:

• Two tabs with the heavy pilot account FAILS ❌
  • A derived value loop starts to happen to Tab A after a few seconds and then both Tabs crash.
• Clearing cache from heavy imported state PASSES ✅
  • Fixed in Expensify/react-native-onyx@57a1564.

[MobileMage]

Proposal

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

On web, with the same account open in two NewDot tabs, three LHN actions performed in Tab A do not propagate to Tab B: pinning/unpinning a report, drafting a comment (which re-orders the LHN), and marking a report as read/unread. The expectation is that Onyx's cross-tab synchronization keeps both tabs' LHN in sync, but the LHN in the second tab never updates until a full reload.

What is the root cause of that problem?

All three actions write to Onyx collection member keys. togglePinnedState merges {isPinned} into report_<id>, saveReportDraftComment merges into reportDraftComment_<id>, and the unread actions (markCommentAsUnread / openReport) merge lastReadTime into report_<id>. These are persisted keys, so on the originating tab Onyx writes them to IndexedDB and raises a cross-tab storage event via InstanceSync (raiseStorageSyncEvent). The receiving tab picks the event up, re-reads the value, and dispatches it. So the write path and the broadcast itself work fine — the failure is entirely in how the receiving tab dispatches the synced value to subscribers.

The LHN reads these collections in useSidebarOrderedReports, subscribing to the whole report_ and reportDraftComment_ collections:

App/src/hooks/useSidebarOrderedReports.tsx

Lines 92 to 97 in 7a4bbdb

	const [chatReports, {sourceValue: reportUpdates}] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [, {sourceValue: policiesUpdates}] = useMappedPolicies(policyMapper);
	const [transactions, {sourceValue: transactionsUpdates}] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION);
	const [transactionViolations, {sourceValue: transactionViolationsUpdates}] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS);
	const [reportNameValuePairs, {sourceValue: reportNameValuePairsUpdates}] = useOnyx(ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS);
	const [reportsDrafts, {sourceValue: reportsDraftsUpdates}] = useOnyx(ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT);

Because these are collection-key subscriptions, useOnyx registers them with waitForCollectionCallback: true (react-native-onyx useOnyx.js L235). The bug is in the cross-tab sync handler installed by Onyx.init (react-native-onyx/dist/Onyx.js L64-L69). When a synced key arrives, it updates the cache and then calls keyChanged with isProcessingCollectionUpdate set to isCollectionMember(key) — which is true for report_<id> and reportDraftComment_<id>:

const isKeyCollectionMember = OnyxKeys.isCollectionMember(key);
OnyxUtils.keyChanged(key, value, undefined, isKeyCollectionMember);

Inside keyChanged (OnyxUtils.js L585-L590), when a subscriber is a waitForCollectionCallback collection subscriber and isProcessingCollectionUpdate is true, the subscriber is continue-skipped — the code assumes a separate collection-level dispatch will follow. The handler's own comment says "individual members sync separately to other tabs". That assumption is wrong for the cross-tab path: InstanceSync raises one storage event per member key and there is no accompanying keysChanged (collection-level) dispatch. So the LHN's collection subscriber is skipped and never re-runs. The cache is updated silently, which is exactly why the data only appears after a reload. This single mechanism explains all three reported cases, since all three back the LHN through report_ / reportDraftComment_ collection subscribers.

The LHN isn't the only waitForCollectionCallback subscriber this skip suppresses on cross-tab syncs — the OnyxDerived dependency subscribers connect the same way, so re-enabling collection subscribers on the sync path also re-enables per-member derived recomputes, which matters for the fix below.

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

Route cross-tab collection-member updates through the collection-level dispatch (keysChanged) instead of keyChanged with the skip flag, batched as a single keysChanged(collectionKey, members) per collection per tick rather than one call per member — matching the local mergeCollection path. That fixes the LHN without turning an N-member sync into N derived recomputes (which is what crashes two heavy tabs).

Also mark the nine persisted derived keys RAM-only alongside the existing RAM_ONLY_SORTED_REPORT_ACTIONS:

App/src/setup/index.ts

Lines 59 to 63 in 7a4bbdb

	ramOnlyKeys: [
	ONYXKEYS.RAM_ONLY_ARE_TRANSLATIONS_LOADING,
	ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE,
	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
	ONYXKEYS.DERIVED.RAM_ONLY_SORTED_REPORT_ACTIONS,

 ramOnlyKeys: [
     // ...existing keys...
     ONYXKEYS.DERIVED.RAM_ONLY_SORTED_REPORT_ACTIONS,
+    ONYXKEYS.DERIVED.REPORT_ATTRIBUTES,
+    ONYXKEYS.DERIVED.REPORT_TRANSACTIONS_AND_VIOLATIONS,
+    ONYXKEYS.DERIVED.OUTSTANDING_REPORTS_BY_POLICY_ID,
+    ONYXKEYS.DERIVED.VISIBLE_REPORT_ACTIONS,
+    ONYXKEYS.DERIVED.NON_PERSONAL_AND_WORKSPACE_CARD_LIST,
+    ONYXKEYS.DERIVED.PERSONAL_AND_WORKSPACE_CARD_LIST,
+    ONYXKEYS.DERIVED.CARD_FEED_ERRORS,
+    ONYXKEYS.DERIVED.TODOS,
+    ONYXKEYS.DERIVED.FLAGGED_EXPENSES,
 ],

They're deterministic functions of base collections that already sync, so each tab recomputes locally; re-broadcasting the results (with skipCacheCheck: true forcing a write every time) is redundant and is what amplifies a heavy two-tab session into a recompute storm.

What alternative solutions did you explore? (Optional)

Simply dropping the isProcessingCollectionUpdate flag (calling keyChanged(key, value) without it) also unblocks the LHN, but it leaves the receiving tab notifying subscribers one member at a time and bypasses the per-dispatch collection snapshot caching that keysChanged provides, so routing through keysChanged is the cleaner, intent-matching fix.

[melvin-bot]

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

[melvin-bot]

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

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

This is an Onyx cross-tab sync bug, not an LHN action-specific bug. The LHN subscribes to collection roots such as REPORT and REPORT_DRAFT_COMMENT, and uses the returned sourceValue to incrementally update the cached LHN report set (App useSidebarOrderedReports, incremental update keys). Those collection subscriptions are created by useOnyx() with waitForCollectionCallback: true for collection keys (Onyx useOnyx).

When Tab A pins a report, saves a draft, or marks a report unread, App writes collection-member keys like report_<id> or reportDraftComment_<id> (pin/draft writes, mark-unread write). On Tab B, web InstanceSync currently sends and loads each changed key separately (Onyx web sync, receiver). Then Onyx.init() calls keyChanged() with isProcessingCollectionUpdate = true for collection members (Onyx init sync callback), but keyChanged() skips collection-root subscribers with waitForCollectionCallback when that flag is true (Onyx keyChanged). So Tab B’s LHN never receives the collection callback/source update it needs to recalculate pinned, draft, unread, and ordering state, even though the individual key is in storage.

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

Fix this in react-native-onyx’s cross-tab sync path. Storage.keepInstancesSync should receive the full batch of changed key/value pairs instead of a single key/value, and InstanceSync should preserve multi-key write boundaries by emitting JSON-array batches for multi-key operations while still accepting the legacy single-key payload format for mixed-version tabs (current single-key storage sync type, current keepInstancesSync).

In Onyx.init()’s sync callback, group incoming collection-member pairs by collection root. For each collection member, capture the previous cached value before cache.set(), update the cache, and then call OnyxUtils.keysChanged(collectionKey, partialCollection, previousCollection) once per collection. keysChanged() already notifies collection-root subscribers with waitForCollectionCallback and passes the partial source collection (Onyx keysChanged), while also notifying member-level subscribers (member notification). Non-collection keys should continue to use keyChanged().

Also chunk large web sync payloads before writing SYNC_ONYX to localStorage, because clearing/importing a heavy Onyx state can produce very large key batches. That keeps cross-tab sync from throwing quota errors while still avoiding the old behavior of firing one whole-collection notification per member, which would be expensive for heavy accounts. With that change, Tab B receives one collection-root notification per affected collection, useOnyx() updates sourceValue, and useSidebarOrderedReports recomputes the relevant LHN rows so pinned reports, draft rows, unread state, and ordering update correctly (LHN recompute path, LHN grouping by pinned/draft, draft/pinned/unread inclusion logic).

What alternative solutions did you explore? (Optional)

I also considered fixing this in App by removing waitForCollectionCallback usages or adding special LHN-only listeners for pinned/draft/unread keys, but that would work around one consumer while leaving the same incorrect collection-root notification behavior for every other Onyx collection subscriber.

Fixed Demo:

Screencast.From.2026-06-29.19-00-22.mp4

[github-actions]

⚠️ @nabi-ebrahimi 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).

[github-actions]

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

[github-actions]

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