[$250] Collapse Onyx collection-key subscriptions to a single whole-collection delivery mode and remove the waitForCollectionCallback option

[mountiny]

Coming from here

Background

A component reads an Onyx collection — the set of records sharing a key prefix, e.g. every report under report_ — through either useOnyx or the imperative Onyx.connect/Onyx.connectWithoutView. Such a subscription delivers updates in one of two modes:

Per-member (the default): the callback fires once per member — on the initial connection, once for each member already present in the collection; on each later write, once for every member whose value changed — as callback(memberValue, memberKey).
Whole-collection (waitForCollectionCallback: true): the callback fires a single time with the entire collection object — callback(collection, collectionKey).

Both modes are backed by the same data: Onyx keeps a frozen object for each collection in its cache, in which members that didn't change retain the same reference across writes. Across all of expensify-app, only three consumers still use per-member mode (Report/index.ts, replaceOptimisticReportWithActualReport.ts, Transaction.ts))); every other collection subscriber uses whole-collection mode.

Problem

When a collection subscription can deliver its data two ways — per-member (the default) or as the whole collection — if an engineer writes, reviews, or changes a collection subscription or the notify code behind it, then they must understand and keep both firing behaviors working even though the two carry the same data. Only three consumers use per-member mode, and each just rebuilds the whole collection it withholds — one of them incorrectly — so the mode adds permanent cost while giving its users nothing whole-collection mode doesn't.

Solution

Remove the waitForCollectionCallback option and the per-member dispatch path, leaving a single delivery mode: a collection subscription always hands back the whole collection object in one callback. This collapses the two-mode choice every collection subscription had to make into one and deletes the dedicated per-member branch from the notification path, so neither new subscriptions nor future changes to the notify code have to reason about it.

Nothing is lost. The collection object already carries every member, so a consumer that needs to know which members changed compares the new object against the previous one — members that didn't change are reference-equal, so the changed set falls out in O(members), with an O(1) check per member. Because per-member mode delivered no information the whole-collection object lacks, it is a strict subset and can be removed outright rather than preserved.

All the three remaining per-member consumers maintain a module-level cache of an entire collection, rebuilt from the per-member callback — exactly what whole-collection mode delivers in one call. Each switches to whole-collection mode and reads the collection object directly:

• Report/index.ts and replaceOptimisticReportWithActualReport.ts subscribe to COLLECTION.REPORT_ACTIONS and accumulate allReportActions[reportID] = actions per member. Both become a single assignment from the collection object, which is already keyed by member (report) ID.
• Transaction.ts subscribes to COLLECTION.TRANSACTION_VIOLATIONS and assigns each fired member into a flat variable (allTransactionViolations = val ?? []), so only the last member to fire survived — a latent bug. Reading the whole collection object instead fixes it.

A consumer that truly needed per-member granularity could recover it by diffing the new collection object against the previous one (reference-equal members fall out in O(members), O(1) each), but none of these three do — they all want the whole collection.

Issue Owner

Current Issue Owner: @fabioh8010

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069451476935700446
• Upwork Job ID: 2069451476935700446
• Last Price Increase: 2026-06-23

[MelvinBot]

Proposal

I validated every claim in this issue against the code at 5351d7be. All three hold, the Transaction.ts latent bug is real, and the dispatch fork exists exactly as described. One important scoping note: removing the option itself is a react-native-onyx change, not an App change — see "Where the work lives" below.

What is the root cause of that problem?

Onyx collection-key subscriptions support two delivery modes, selected per subscription via waitForCollectionCallback:

• Whole-collection (waitForCollectionCallback: true): one callback with the full frozen collection object.
• Per-member (default): one callback per changed member, callback(memberValue, memberKey).

Both are backed by the same frozen cache snapshot, in which unchanged members keep the same reference across writes — so per-member delivers no information the whole-collection object lacks. The two-mode fork is permanent cognitive/maintenance cost in the notify path (OnyxUtils keysChanged / keyChanged / initial broadcast each branch on the flag), and in App only three consumers still use per-member mode — and they all just rebuild the whole collection anyway, one of them incorrectly.

Evidence — the three per-member consumers (exhaustive scan, these are the only three in src/)

1. Report/index.ts:456-465 — Onyx.connect on REPORT_ACTIONS, accumulates allReportActions[reportID] = actions. Correct.
2. replaceOptimisticReportWithActualReport.ts:46-57 — Onyx.connectWithoutView on REPORT_ACTIONS, same per-key accumulation. Correct.
3. Transaction.ts:98-102 — Onyx.connect on TRANSACTION_VIOLATIONS with callback: (val) => (allTransactionViolations = val ?? []). allTransactionViolations is a flat TransactionViolation[], overwritten on every per-member fire, so only the last member that fired survives. This is a latent bug.

A paren-balanced scan of all .ts/.tsx under src/ for Onyx.connect/connectWithoutView on COLLECTION.* keys without waitForCollectionCallback returned exactly these three — nothing missed.

Evidence — the Transaction.ts bug is actually consumed wrong

The only reader is Transaction.ts:1160-1166, which writes allTransactionViolations (filtered) to every duplicate transaction's violations key — treating the last-fired member's violations as if they belonged to all duplicates. Notably, the REPORT subscriber 12 lines above in the same file already uses waitForCollectionCallback: true, so the violations subscriber omitting it reads as an oversight, not intent.

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

Two PRs, in this order:

1. App PR (can be done now, independently): switch the three consumers to whole-collection mode.
   • The two REPORT_ACTIONS consumers add waitForCollectionCallback: true and replace the per-member accumulation with a single assignment from the collection object (it's already keyed by reportID).
   • Transaction.ts adds waitForCollectionCallback: true and reads the whole collection object, then indexes by the relevant transaction ID at the consumption site — this fixes the latent bug as a side effect.
2. react-native-onyx PR (the actual option removal): delete waitForCollectionCallback from the connect options type and remove the per-member dispatch branches in OnyxUtils (keysChanged, keyChanged, the initial broadcast), leaving the whole-collection path always. Then bump the version in App.

A consumer that ever genuinely needs per-member granularity can recover it by diffing the new frozen collection against the previous one (unchanged members are reference-equal, O(members) with O(1) per member) — but none of the three do.

Where the work lives (scoping)

waitForCollectionCallback and the per-member dispatch path are defined in Expensify/react-native-onyx (v3.0.85), a separate repo from Expensify/App. The core of this issue — removing the option — must be implemented there and released, not in App. I confirmed the dispatch fork in the compiled library (OnyxUtils branches on subscriber.waitForCollectionCallback; OnyxCache rebuilds a frozen snapshot reusing unchanged member references, and useOnyx already forces whole-collection mode for every collection key). Step 1 (the three consumer migrations) is fully within App and is what I can implement here; step 2 needs an engineer with access to the onyx repo.

What alternative solutions did you explore? (Optional)

Keeping per-member mode but documenting it better — rejected: it carries no information whole-collection lacks, so it's strictly removable rather than worth preserving.

Confidence & how this was verified

High. Two independent code investigations confirmed: (a) the three per-member consumers are the only ones in src/ and the Transaction.ts flat-overwrite bug is real and mis-consumed; (b) the dispatch fork and reference-equal frozen-snapshot caching exist as described in the library, and the library is a separate repo. No production logs needed — the defect is unambiguous at the code level, though its runtime impact depends on how often the duplicate-transaction path runs with multiple violation members.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94331) to create a draft PR (App-side step 1 only — the onyx repo change needs an internal engineer).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

This is a tech-debt / latent-bug issue, not a UI regression. An Onyx collection subscription can deliver data two ways — per-member (the default) or whole-collection (waitForCollectionCallback: true) — yet both are backed by the same frozen, reference-stable collection object in Onyx's cache. Every collection subscriber that still uses per-member mode just rebuilds the whole collection it is fed one member at a time, so the per-member dispatch path costs maintenance forever while giving its consumers nothing whole-collection mode doesn't.

Across the App only three subscribers remain on per-member mode, and each keeps a module-level cache it reconstructs by hand:

1. Report/index.ts — Onyx.connect(COLLECTION.REPORT_ACTIONS) accumulates allReportActions[reportID] = actions per member, keying by the bare reportID via CollectionUtils.extractCollectionItemID(key):
   

   App/src/libs/actions/Report/index.ts

   Lines 456 to 465 in be8591c

   	Onyx.connect({
   	key: ONYXKEYS.COLLECTION.REPORT_ACTIONS,
   	callback: (actions, key) => {
   	if (!key || !actions) {
   	return;
   	}
   	const reportID = CollectionUtils.extractCollectionItemID(key);
   	allReportActions[reportID] = actions;
   	},
   	});

2. replaceOptimisticReportWithActualReport.ts — same pattern on COLLECTION.REPORT_ACTIONS, also keyed by bare reportID:
   

   App/src/libs/actions/replaceOptimisticReportWithActualReport.ts

   Lines 48 to 57 in be8591c

   	Onyx.connectWithoutView({
   	key: ONYXKEYS.COLLECTION.REPORT_ACTIONS,
   	callback: (actions, key) => {
   	if (!key || !actions) {
   	return;
   	}
   	const reportID = key.replace(ONYXKEYS.COLLECTION.REPORT_ACTIONS, '');
   	allReportActions[reportID] = actions;
   	},
   	});

3. Transaction.ts — Onyx.connect(COLLECTION.TRANSACTION_VIOLATIONS) assigns each fired member into a flat variable:
   

   App/src/libs/actions/Transaction.ts

   Lines 98 to 102 in be8591c

   	let allTransactionViolations: TransactionViolations = [];
   	Onyx.connect({
   	key: ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS,
   	callback: (val) => (allTransactionViolations = val ?? []),
   	});

Consumer #3 carries a real, latent bug. allTransactionViolations is overwritten on every member callback, so only the last transaction's violations ever survive in it. When clearing duplicate violations on unreport, the code loops over each duplicate id but pulls violations from that one stale flat array instead of from each id's own record:

App/src/libs/actions/Transaction.ts

Lines 1156 to 1167 in be8591c

	// Optimistically clear all violations for the transaction when moving to self DM report
	if (isUnreported) {
	const duplicateViolation = currentTransactionViolations?.[transaction.transactionID]?.find((violation) => violation.name === CONST.VIOLATIONS.DUPLICATED_TRANSACTION);
	const duplicateTransactionIDs = duplicateViolation?.data?.duplicates;
	if (duplicateTransactionIDs) {
	for (const id of duplicateTransactionIDs) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${id}`,
	value: allTransactionViolations.filter((violation: TransactionViolation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION),
	});
	}

So: per-member mode → three hand-rolled whole-collection caches → permanent dual-path cost, and in Transaction.ts a flat-variable cache that silently keeps only the last member → wrong violations written for every duplicate id.

One precision note on the migration (the issue text says each cache "becomes a single assignment from the collection object, which is already keyed by member (report) ID"): whole-collection mode hands back an object keyed by the full Onyx key, not the bare ID. The existing whole-collection subscribers in these very files prove it — they index by full key:

• replaceOptimisticReportWithActualReport.ts REPORT cache, read as allReports?.[${COLLECTION.REPORT}${preexistingReportID}]:

  App/src/libs/actions/replaceOptimisticReportWithActualReport.ts

  Lines 238 to 256 in be8591c

  	Onyx.connectWithoutView({
  	key: ONYXKEYS.COLLECTION.REPORT,
  	waitForCollectionCallback: true,
  	callback: (value: OnyxCollection<Report>) => {
  	allReports = value;
  	if (!value) {
  	return;
  	}
  	for (const report of Object.values(value)) {
  	if (!report) {
  	continue;
  	}
  	replaceOptimisticReportWithActualReport(report, allReportDraftComments?.[`${ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT}${report.reportID}`]);
  	}
  	},
  	});

• Transaction.ts REPORT cache:

  App/src/libs/actions/Transaction.ts

  Lines 86 to 96 in be8591c

  	let allReports: OnyxCollection<Report> = {};
  	Onyx.connect({
  	key: ONYXKEYS.COLLECTION.REPORT,
  	waitForCollectionCallback: true,
  	callback: (value) => {
  	if (!value) {
  	return;
  	}
  	allReports = value;
  	},
  	});

That matters for the two REPORT_ACTIONS caches, whose ~7 downstream readers index by bare reportID (e.g. allReportActions?.[parentReportID]?.[parentReportActionID] at replaceOptimisticReportWithActualReport.ts L78 / L116, and Report/index.ts L1177, L2996, L3051, L6279, L6489, L6850). A naive allReportActions = value would break all of them.

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

Remove the waitForCollectionCallback option and the per-member dispatch branch from the notify path in react-native-onyx (separate library PR, since the option lives in the dependency, not the App). On the App side, migrate the three subscribers to whole-collection delivery:

Transaction.ts — flip the subscription to waitForCollectionCallback: true, type the cache as OnyxCollection<TransactionViolations> (the type is already imported and is exactly the shape used elsewhere, e.g. Transaction.ts#L6154), and read each id's own violations in the loop instead of the flat array. This fixes the latent bug for free:

let allTransactionViolations: OnyxCollection<TransactionViolations> = {};
Onyx.connect({
    key: ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS,
    waitForCollectionCallback: true,
    callback: (value) => (allTransactionViolations = value ?? {}),
});
// in the loop (L1165): read per-id, not the flat array
value: allTransactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${id}`]?.filter(
    (violation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION,
) ?? [],

Report/index.ts and replaceOptimisticReportWithActualReport.ts — flip both REPORT_ACTIONS subscriptions to waitForCollectionCallback: true. Because the downstream readers index by bare reportID, keep the cache bare-keyed by reusing the helper already in scope, CollectionUtils.extractCollectionItemID (already imported and used at Report/index.ts#L462), to re-key the whole object once per callback:

callback: (value) => {
    const next: OnyxCollection<ReportActions> = {};
    for (const [key, actions] of Object.entries(value ?? {})) {
        next[CollectionUtils.extractCollectionItemID(key as `${OnyxCollectionKey}${string}`)] = actions;
    }
    allReportActions = next;
},

This stays O(members) in a single callback (vs. N callbacks today), leaves every downstream bare-key reader untouched, and mirrors the existing whole-collection caches already in these files. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

For the two REPORT_ACTIONS caches, do a literal one-line allReportActions = value (full-keyed) and rewrite each of the ~7 downstream lookups to use the full key ${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID} (matching the existing allReports access pattern). This is closer to "a single assignment," but it touches every reader across Report/index.ts and risks missing one, whereas re-keying once inside the callback via the already-imported extractCollectionItemID is contained, lower-risk, and keeps the rest of the file unchanged.

[ahmdshrif]

Proposal

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

Onyx collection subscriptions support two delivery modes — per-member (default) and whole-collection (waitForCollectionCallback: true) — that carry identical data. Only three consumers still use the per-member path, and each just rebuilds the whole collection it withholds (one with a latent bug). We want to delete the per-member dispatch path and the waitForCollectionCallback option so every collection subscription has one behavior.

What is the root cause of that problem?

This is a cleanup, so the "root cause" is the redundant second mode plus the work needed to retire it safely.

1. The waitForCollectionCallback option and the per-member-vs-whole-collection dispatch branch live in react-native-onyx (App pins it at package.json#L198, 3.0.85). The two modes read the same frozen per-collection cache, so the per-member branch is pure surface area.

2. Three App consumers depend on the default (per-member) mode:

   • Report/index.ts#L456-L465 — allReportActions[reportID] = actions, keyed by bare reportID via extractCollectionItemID.
   • replaceOptimisticReportWithActualReport.ts#L47-L57 — same pattern via connectWithoutView, bare key.replace(prefix,'').
   • Transaction.ts#L98-L102 — allTransactionViolations = val ?? [] assigns each fired member into one flat array, so only the last transaction's violations survive (the latent bug).

3. Key-shape trap (the part the description understates). Whole-collection mode delivers an object keyed by full Onyx keys (reportActions_123), not the bare member ID. Every existing whole-collection consumer already reads it that way — e.g. ReportActionsUtils.ts#L97-L107 indexes allReportActions?.[${COLLECTION.REPORT_ACTIONS}${reportID}]. But the two REPORT_ACTIONS caches above are read with bare IDs at ~10 sites (Report/index.ts L1177, L2995, L3050, L4586, L6278, L6488, L6849; replaceOptimisticReportWithActualReport.ts L78, L116). A bare allReportActions = actions re-keys the cache and silently returns undefined at all of them.

4. Blast radius of removing the option. Removing waitForCollectionCallback from the type means the 62 occurrences across 28 files that currently pass waitForCollectionCallback: true must also be deleted, or TypeScript fails (ReportUtils.ts, IOU/index.ts, App.ts, Pagination.ts, OnyxDerived/index.ts, registerPaginationConfig.ts, addUtilsToWindow.ts, …). The description names only the 3 per-member consumers; these 28 are the real diff.

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

In react-native-onyx: drop the waitForCollectionCallback option from the connect options type and delete the per-member branch in the notify/send path so a collection connection always fires once with the whole collection object. Keep the frozen per-collection cache untouched (reference-equal unchanged members are preserved — a consumer that ever needs the changed set diffs old vs new in O(members)). Publish + bump the pin in package.json.

In App (same release):

• Convert the three consumers to whole-collection. For the two REPORT_ACTIONS caches use the cheapest form — allReportActions = actions (one reference assignment per write) — and update their ~10 read sites to the prefixed key allReportActions?.[${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}], matching ReportActionsUtils. For Transaction.ts, type allTransactionViolations as OnyxCollection<TransactionViolation[]> keyed by full key (mirroring the file's already-correct allTransactionViolation param at #L841) and fix the consumer at #L1165 to index allTransactionViolations?.[${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${id}] — closing the latent bug.
• Delete the 62 waitForCollectionCallback: true lines across the 28 files above.

Regression safety: the frozen cache is unchanged, so every already-whole-collection subscriber gets byte-identical data; only the 3 converted consumers + their reads change.

Why the simple fix (just convert the 3 callbacks) fails: (a) a bare allReportActions = actions flips the cache from bare to prefixed keys, so all ~10 downstream reads return undefined; and (b) you cannot land the Onyx removal alone — the default flips from per-member to whole-collection, so the instant the option is gone these 3 consumers silently receive the whole object and corrupt their caches unless converted in the same release.

What alternative solutions did you explore? (Optional)

• Re-key on assignment to preserve bare keys and avoid touching the reads (Object.fromEntries(Object.entries(actions).map(([k,v]) => [extractCollectionItemID(k), v]))). Rejected — it rebuilds the map on every collection write, re-introducing exactly the per-member O(members) cost this issue exists to delete. Re-pointing the reads is free at runtime.
• Deprecate the option as a no-op instead of removing it. Rejected — leaves the dual-mode surface area the issue wants gone and 62 dead flags in place.

[lorretheboy]

Proposal

What is the root cause of that problem?

Onyx exposes two delivery modes for a collection subscription that carry identical data: per-member (default) and whole-collection (waitForCollectionCallback: true). The mode only exists today because three consumers still use the default, and each merely reassembles the whole collection the mode withholds — so it is permanent dual-path cost (every author/reviewer of the notify code must keep both branches working) for zero information gain.

One of those three does the reassembly incorrectly. Transaction.ts subscribes to the whole TRANSACTION_VIOLATIONS collection in per-member mode but assigns each fired member into a single flat array variable, so only the last member to fire survives:

App/src/libs/actions/Transaction.ts

Lines 98 to 102 in 5351d7b

	let allTransactionViolations: TransactionViolations = [];
	Onyx.connect({
	key: ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS,
	callback: (val) => (allTransactionViolations = val ?? []),
	});

That stale single-member value is then filtered and written to every duplicate transaction's key, instead of each duplicate's own violations:

App/src/libs/actions/Transaction.ts

Line 1165 in 5351d7b

value: allTransactionViolations.filter((violation: TransactionViolation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION),

The other two consumers reassemble correctly into a collection map but still pay the per-member cost:

App/src/libs/actions/Report/index.ts

Lines 456 to 465 in 5351d7b

	Onyx.connect({
	key: ONYXKEYS.COLLECTION.REPORT_ACTIONS,
	callback: (actions, key) => {
	if (!key || !actions) {
	return;
	}
	const reportID = CollectionUtils.extractCollectionItemID(key);
	allReportActions[reportID] = actions;
	},
	});

App/src/libs/actions/replaceOptimisticReportWithActualReport.ts

Lines 48 to 57 in 5351d7b

	Onyx.connectWithoutView({
	key: ONYXKEYS.COLLECTION.REPORT_ACTIONS,
	callback: (actions, key) => {
	if (!key || !actions) {
	return;
	}
	const reportID = key.replace(ONYXKEYS.COLLECTION.REPORT_ACTIONS, '');
	allReportActions[reportID] = actions;
	},
	});

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

Convert all three consumers to whole-collection mode (waitForCollectionCallback: true) and read the collection object directly, then drop the per-member dispatch branch and the waitForCollectionCallback option in react-native-onyx so only one delivery mode remains.

• Report/index.ts and replaceOptimisticReportWithActualReport.ts: the collection object is already keyed by report ID, so the per-member accumulation collapses into a single assignment of the whole object to allReportActions.

• Transaction.ts: store the whole collection (type OnyxCollection<TransactionViolations>, default {}) instead of a flat array. This also fixes the latent bug — at the duplicate-clearing site read the specific member by key rather than the last-fired value:

App/src/libs/actions/Transaction.ts

Line 1165 in 5351d7b

value: allTransactionViolations.filter((violation: TransactionViolation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION),

i.e. allTransactionViolations[${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${id}]?.filter(...) ?? [], so each duplicate gets its own violations minus the DUPLICATED_TRANSACTION entry.

A consumer that genuinely needed to know which members changed can diff the new collection object against the previous one (unchanged members are reference-equal), but none of these three do.

What alternative solutions did you explore? (Optional)

Fix only the Transaction.ts member-overwrite bug (switch it to whole-collection mode) and leave per-member mode in place. This repairs the incorrect behavior but keeps the redundant dual delivery path the issue is asking to remove.

[Abdulloh0109]

What is the root cause of that problem?

This isn't a user-facing defect so much as accumulated cost from a dual-mode API plus one latent bug it hides. An Onyx collection subscription can deliver data two ways, and both are backed by the same frozen collection object (unchanged members keep reference equality across writes), so per-member mode hands consumers nothing the whole-collection object doesn't already carry. Keeping it alive means the notification path carries a dedicated per-member branch — the else loop in keysChanged, the matching branch in keyChanged, and the per-key initial-connection delivery in react-native-onyx's OnyxUtils — that every engineer touching that code (or writing any new collection subscription) has to reason about.

Only three consumers still use per-member mode, and each immediately rebuilds the whole collection the mode withholds:

• Report/index.ts#L456-L465 accumulates allReportActions[reportID] = actions per member.
• replaceOptimisticReportWithActualReport.ts#L48-L57 does the same.
• Transaction.ts#L98-L102 is the broken one: callback: (val) => (allTransactionViolations = val ?? []) writes each fired member into a flat variable, so only the last member to fire survives.

That last point isn't theoretical. At Transaction.ts#L1156-L1168, the unreported-move path loops over duplicateTransactionIDs and writes allTransactionViolations.filter(v => v.name !== DUPLICATED_TRANSACTION) into transactionViolations_<id> for every id — but allTransactionViolations only holds whichever transaction fired into the module variable last, not the violations belonging to id. So every duplicate gets some other transaction's violation set.

One subtlety the issue's "Solution" understates, and that decides whether the fix is correct: the whole-collection object is not keyed by bare report ID. It's keyed by the full member key (reportActions_<id>, transactionViolations_<id>) — you can see this in every existing whole-collection consumer, e.g. allReports?.[${ONYXKEYS.COLLECTION.REPORT}${reportID}] at Report/index.ts#L2090. But the per-member consumers strip the prefix — CollectionUtils.extractCollectionItemID(key) (which is key.split('_').at(1)) in Report/index.ts, key.replace(...) in replaceOptimistic — and every downstream read indexes by the bare id: allReportActions?.[reportID] at Report/index.ts#L1177 and at L2995/L3050/L4586/L6278/L6488/L6849, plus allReportActions?.[parentReportID] at replaceOptimisticReportWithActualReport.ts#L78 and L116. So a literal allReportActions = value re-keys the cache from bare id to full member key, and all of those reads silently return undefined. The migration has to preserve the existing key shape, not just flip the mode flag.

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

Two layers, staged, since the Onyx removal is cross-repo.

1. Migrate the three App consumers off per-member mode (data layer).

• Report/index.ts and replaceOptimistic genuinely need a module-level cache read across many functions, so flip them to waitForCollectionCallback: true — but in the callback, rebuild the cache keyed by the bare id (iterate the delivered object, strip each reportActions_ prefix, assign under the stripped id). That keeps all ~9 read sites untouched and stays O(members) per write, exactly like today, just in one callback instead of N. Re-keying every reader to the full key is the alternative, but it's a bigger, riskier diff for no gain.
• Transaction.ts doesn't need a new subscription at all. Its allTransactionViolations module cache has a single reader (L1165), inside a function that already receives the whole violations collection as the allTransactionViolation param (Transaction.ts#L856) and builds a correctly bare-id-keyed local from it at Transaction.ts#L875-L877. So delete the L98-L102 subscription outright and repoint L1165 to read that id's own violations from the in-scope collection — allTransactionViolation?.[${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${id}]?.filter(v => v.name !== DUPLICATED_TRANSACTION) ?? []. That removes a per-member consumer and fixes the latent bug in one move, without adding a whole-collection subscription.

2. Remove the per-member path and the option from react-native-onyx (notify layer), then bump App's dependency.

In OnyxUtils, collapse keysChanged and keyChanged to always take the whole-collection branch (delete the per-member else loops), drop the per-key initial-connection delivery, and remove waitForCollectionCallback from the connection/mapping types and from useOnyx. Per-member carried no information the collection object lacks, so this is a strict-subset removal — no downstream shim needed. It must publish in react-native-onyx first (or alongside), then App bumps past 3.0.83. Step 1 works on the currently published Onyx because the option still exists there, so the two stage cleanly.

No offline/optimistic concern: all three caches are read-only module mirrors, and the Transaction.ts change only alters which violations land in optimisticData, which already rolls back via the existing failureData.

What alternative solutions did you explore? (Optional)

• Just fix Transaction.ts in place, keep per-member mode. Rejected: it patches the visible bug but leaves the dual-mode API and the dispatch branch the issue is explicitly trying to delete — symptom, not goal.
• Do the literal allReportActions = value single assignment from the issue text. Rejected by code: getCachedCollection keys the delivered object by full member key while every reader indexes by bare id, so this regresses all ~9 read sites to undefined. The migration must preserve the bare-id shape on assignment (recommended) or re-key every reader.
• Convert Transaction.ts's allTransactionViolations to a whole-collection OnyxCollection and keep the subscription. Rejected as redundant: the only reader sits inside a function that already has the whole collection in scope, so the subscription is dead weight once L1165 is repointed — deleting it is cleaner than converting it.
• Add a generic diffCollection(prev, next) helper for future consumers needing changed-member granularity. Deferred — none of the three want per-member granularity, so building it now is speculative; reference-equality makes it a cheap follow-up if a real need appears.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.