[Due for payment 2026-07-17] [$250] Coalesce OnyxDerived recomputes into one macrotask flush

[mountiny]

Coming from a proposal https://expensify.slack.com/archives/C08CZDJFJ77/p1783094934084619?thread_ts=1782801937.464879&cid=C08CZDJFJ77

Proposal: Coalesce OnyxDerived recomputes into one macrotask flush

Background

OnyxDerived values (e.g. reportAttributes) are precomputed values stored in Onyx so that expensive computations shared across the app run once instead of in every consumer. Each derived value declares a list of Onyx dependencies and opens one connection per dependency; whenever a dependency broadcasts a change, the connection callback runs the derived value's compute function. reportAttributes alone declares 13 dependencies (reports, transactions, violations, report actions, NVPs, policies, personal details, etc.) and is among the heaviest computes in the app. Critically, Onyx delivers a single logical write (such as a server response that touches reports, transactions, and violations together) as several separate broadcasts spread across microtasks, and each derived dependency is connected independently.

Problem

When a single logical Onyx update touches several dependencies of a derived value, each dependency's connection callback fires its own synchronous recompute, so one change recomputes the derived value many times back-to-back, blocking the JS thread and dropping frames during startup and report opens.

Solution

Coalesce the per-dependency callbacks for each derived value into a single compute, scheduled on the next macrotask, and reconstruct the changed-member delta at flush time:

1. Coalescing. recomputeDerivedValue no longer computes inline. It records the triggering dependency in a pending set and, if no flush is already scheduled, schedules one via setTimeout(flushRecompute, 0). Every dependency callback from the same logical update lands in that one pending flush, so N recomputes collapse to 1.
2. Flush-time delta reconstruction. Rather than depending on Onyx's per-broadcast sourceValue (which doesn't survive coalescing — you'd be merging N partial payloads — and is a mechanism being phased out), the flush reconstructs the delta itself. For each collection dependency that fired, it diffs the current snapshot against a baseline snapshot captured at the previous flush, using a new shared getCollectionDelta helper. Onyx's structural sharing keeps unchanged members reference-equal, so this is a cheap reference scan that yields exactly the changed members. Non-collection dependencies pass their whole value. The first flush has no baselines, so it computes from scratch (no sourceValues → full compute) and captures the initial baselines for subsequent diffs.
3. Incremental configs are hardened to honor every coalesced trigger. Configs that update incrementally previously assumed a compute was triggered by a single dependency. Coalescing can now deliver several changed dependencies in one compute, so any config that branched on "which one changed" was updated to process all of them, namely reportAttributes, reportTransactionsAndViolations and sortedReportActions.

With recomputes coalesced, one logical update produces exactly one compute of each derived value instead of one-per-dependency, removing the redundant passes that block the thread. Derived values become eventually consistent within one macrotask of the originating write — consumers re-render normally through useOnyx when the single updated value lands.

Measured results (Applause heavy account)

• ManualAppStartup (inbox tab) = 2717 ms -> 2708 ms (−0.3%) (stable, no perf regressions)
• ManualSendMessage = 168 ms -> 84 ms (−50.0%)
• Derived computation after startup and ReconnectApp call
  • Total time = 575 ms -> 215 ms (−62.6%)
  • Dependencies changes = 62 -> 62 (expected, we want to see improvements in the recomputes)
  • Recomputes = 62 -> 19 (−69.4%)
  • On main, reportAttributes fired ~14 times/run, including a burst of large ones (123 + 105 + 101 + 75 ≈ 404 ms of compute).
  • On the solution branch, reportAttributes fires ~4 times/run, with a single large compute (~110 ms) instead of four.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022073092002479955520
• Upwork Job ID: 2073092002479955520
• Last Price Increase: 2026-07-03

Issue Owner

Current Issue Owner: @shubham1206agra

Issue Owner

Current Issue Owner: @shubham1206agra

[MelvinBot]

Analysis

This issue is a performance proposal (coalesce N per-dependency OnyxDerived recomputes into 1 macrotask flush), not a bug report — so this is a technical validation of the proposal rather than a root-cause analysis. Verdict: the proposal's description of the current architecture is accurate and the approach is sound, but there are two concrete correctness risks the implementation must handle.

Verified against code (8f9ac4c):

• Recompute is inline/synchronous today — each dependency broadcast calls compute() immediately inside the Onyx callback, so one logical multi-collection write triggers N synchronous recomputes. OnyxDerived/index.ts:68-103
• reportAttributes declares 14 dependencies (proposal says "~13") and is the heaviest compute. configs/reportAttributes.ts:86-101
• No coalescing/debounce exists today — recompute is strictly 1:1 with broadcasts.
• The three named incremental configs do branch on "which dependency changed" via sourceValues, so they genuinely must be updated to process all coalesced triggers: reportAttributes.ts:123-182, reportTransactionsAndViolations.ts:16-32, sortedReportActions.ts:54-87. (visibleReportActions.ts also branches on sourceValues and should be checked for the same assumption.)

⚠️ Two risks to handle in implementation

1. Synchronous readers get one-macrotask-stale data. Deferring recompute means any code path that writes a dependency and then synchronously reads the derived value in the same tick sees the old value. ReportUtils caches reportAttributesDerivedValue and reads it non-reactively in many synchronous utilities — e.g. getReportName and getReportPreviewMessage (ReportUtils.ts:1217-1221). Reactive useOnyx consumers are safe (they re-render on the eventual write); synchronous utility reads are the exposure. Worth auditing write→sync-read sequences before merging.

2. Tests assuming synchronous derivation will need updating. tests/unit/OnyxDerivedTest.tsx mixes patterns — some await waitForBatchedUpdates() (which drains setTimeout(0), likely fine) but some write then immediately await OnyxUtils.get(...) with no batched-update wait, which relies on inline recompute and will break under a deferred flush. Timer mode (fake vs real) matters for the setTimeout(0) flush.

Notes / claims not verifiable from this checkout

• The claim that Onyx sourceValue is "being phased out" is a roadmap statement not evidenced in this checkout — worth confirming against react-native-onyx.
• The claim that sourceValue "doesn't survive coalescing" is subtly imprecise: within a single Onyx.multiSet, Onyx does build a per-collection partial passed as sourceValue. The claim really applies to the cross-broadcast coalescing the proposal itself introduces (the pending set spanning multiple microtask broadcasts), where no single sourceValue covers all triggers — which is exactly why the getCollectionDelta baseline-diff replacement is needed. The structural-sharing assumption behind that diff holds: keysChanged/keyChanged already rely on reference equality for unchanged members.
• No likely-duplicate open issues found in a quick scan.

Confidence: High on the code claims (all verified); the two roadmap/Onyx-internal points above are flagged as unverified.

---

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

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 17:14:12 UTC.

Proposal

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

Derived Onyx values like reportAttributes recompute far more often than they need to. A single logical write from the server (say a response that touches reports, transactions, and violations at once) arrives as several separate Onyx broadcasts, and each one fires its own synchronous recompute of the same derived value. On a heavy account that means the same expensive compute runs back-to-back many times over, blocking the JS thread and dropping frames during startup and when opening a report.

What is the root cause of that problem?

The recompute runs inline, once per dependency broadcast. In src/libs/actions/OnyxDerived/index.ts, each dependency opens its own connectWithoutView connection, and every callback ends with a synchronous call to recomputeDerivedValue(...) — collection deps at line 116, non-collection at line 146, locale at line 136. recomputeDerivedValue (lines 68-103) calls compute() immediately and writes the result with setDerivedValue → Onyx.set. There is no batching between callbacks.

So the fan-out is structural. reportAttributes declares 14 dependencies (configs/reportAttributes.ts:86-101) and is the heaviest compute in the set. When one server response lands across, say, four collections, the connection layer delivers four broadcasts across four microtasks, and reportAttributes computes four times for what is logically one update. The measured burst on main is roughly 123 + 105 + 101 + 75 ≈ 404 ms of compute for a single ReconnectApp, and across the run 62 dependency changes produce 62 recomputes. This is original design, not a regression — the 1:1 recompute-per-broadcast behavior has been there since the derived layer was built.

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

Coalesce the per-dependency callbacks into one flush per macrotask. recomputeDerivedValue should stop computing inline: instead it records the triggering dependency in a pending set and, if no flush is scheduled, schedules one with setTimeout(flushRecompute, 0). Every callback from the same logical update lands in that one pending flush, so N recomputes collapse to 1. This has to sit behind the existing areAllConnectionsSet gate (lines 49-81) so nothing schedules before all connections are up.

Because no single Onyx sourceValue spans coalesced broadcasts anymore, the flush needs to reconstruct the delta itself. Add a shared getCollectionDelta(prevSnapshot, currentSnapshot) helper (it doesn't exist yet) that diffs the current collection against a baseline captured at the previous flush. Onyx keeps unchanged members reference-equal through structural sharing, so this is a cheap reference scan that yields exactly the changed members. Non-collection deps pass their whole value. The first flush has no baseline, so it computes from scratch and captures the initial baselines.

The incremental configs then need to honor every trigger in a flush rather than assuming a single dependency changed. reportAttributes.ts (branches on hasKeyTriggeredCompute/sourceValues, 123-182), reportTransactionsAndViolations.ts (23-32, picks transactions xor violations), and sortedReportActions.ts (57-87) all need this. sortedReportActions is the subtle one: its incremental path keys only on reportActionsUpdates, so a coalesced REPORT change that alters getOneTransactionThreadReportID or chatReportID for a report whose actions didn't change is currently missed — it must also process the report updates. And visibleReportActions.ts (48-84) should get the same treatment even though it isn't in the original list; its session-first branch stays safe, but its incremental branch keys on reportActionsUpdates the same way and would silently drop coalesced triggers.

The real correctness risk to guard is synchronous stale reads. Deferring the recompute means any code that writes a dependency and then reads the derived value in the same tick gets one-macrotask-old data. ReportUtils.ts caches reportAttributesDerivedValue non-reactively (1217-1221) and reads it in getReportName/preview helpers at 5593, 5929, 6103, 8903, 12740, 12743. The ~36 useOnyx consumers are fine — they re-render on the eventual write — but those synchronous util reads need auditing before merge. One more thing to check in reportTransactionsAndViolations.ts:96: the violationInSourceValues === undefined || (...) guard encodes "removed vs absent" semantics that shift when the delta comes from a diff instead of a sourceValue.

On tests, tests/unit/OnyxDerivedTest.tsx mostly await waitForBatchedUpdates() (which drains the setTimeout(0)) so it stays green, but any write→immediate-OnyxUtils.get without that wait relies on inline recompute and will break — add the wait. We should also add the two tests that are missing today: one that writes multiple dependencies in a single logical update and asserts exactly one recompute, and one for delta reconstruction (baseline diff returns exactly the changed members, first flush computes in full). Re-run CardFeedErrorsDerivedValueTest.ts too since it exercises the same path.

What alternative solutions did you explore? (Optional)

Batching at the Onyx broadcast layer would fix this at the source, but that lives in react-native-onyx and is out of scope for this repo — the connection-layer coalescing is the correct in-App fix. I also considered whether coalescing even helps if compute is O(all reports), but the configs already update incrementally keyed on the changed members, so per-compute cost is delta-bounded and collapsing N→1 is a real win, not a constant factor (575 → 215 ms, recomputes 62 → 19 in the measured run).

[lorretheboy]

Proposal

What is the root cause of that problem?

Each derived value opens one Onyx connection per dependency, and every connection callback runs the full compute synchronously, inline:

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

Lines 110 to 118 in 8f9ac4c

	Onyx.connectWithoutView({
	key: dependencyOnyxKey,
	waitForCollectionCallback: true,
	callback: (value, collectionKey, sourceValue) => {
	Log.info(`[OnyxDerived] dependency ${collectionKey} for derived key ${key} changed, recomputing`);
	setDependencyValue(dependencyIndex, value as Parameters<typeof compute>[0][typeof dependencyIndex]);
	recomputeDerivedValue(dependencyOnyxKey, sourceValue, dependencyIndex);
	},
	});

recomputeDerivedValue computes immediately on every call, with sourceValues built from only the single triggering key:

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

Lines 83 to 102 in 8f9ac4c

	context.currentValue = derivedValue;
	context.sourceValues = sourceKey && sourceValue !== undefined ? {[sourceKey]: sourceValue} : undefined;
	const spanId = `${CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE}_${key}`;
	startSpan(spanId, {
	name: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	op: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	parentSpan: getSpan(CONST.TELEMETRY.SPAN_APP_STARTUP),
	attributes: {derivedKey: key},
	});
	try {
	// @ts-expect-error TypeScript can't confirm the shape of dependencyValues matches the compute function's parameters
	const newDerivedValue = compute(dependencyValues, context);
	Log.info(`[OnyxDerived] updating value for ${key} in Onyx`);
	derivedValue = newDerivedValue;
	setDerivedValue(key, derivedValue);
	} finally {
	endSpan(spanId);
	}

Onyx delivers one logical write (e.g. an OpenApp/ReconnectApp response touching reports, transactions, violations, report actions, policies together) as separate per-key broadcasts spread across microtasks. So a single logical update fires several of these callbacks back-to-back, and a heavy derived value like reportAttributes — which declares 14 dependencies — recomputes once per touched dependency instead of once per update. Those redundant synchronous passes block the JS thread during startup and report opens.

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

Coalesce all per-dependency triggers for a derived value into a single compute per macrotask, in recomputeDerivedValue (the one convergence point all callbacks go through):

1. Instead of computing inline, add the triggering dependency to a pending set and, if no flush is scheduled yet, schedule one with setTimeout(flush, 0). All broadcasts from the same logical update (which land within microtasks) collapse into that one flush.
2. At flush time, rebuild sourceValues ourselves instead of relying on Onyx's per-broadcast sourceValue (which can't be meaningfully merged across N partial broadcasts and is being phased out). For each pending collection dependency, diff the current collection against a baseline snapshot kept from the previous flush — Onyx's structural sharing keeps unchanged members reference-equal, so a shallow reference scan yields exactly the changed members cheaply. Non-collection dependencies pass their whole value. On the very first flush there are no baselines, so pass sourceValues: undefined, which the configs already treat as "full compute".
3. Harden the incremental configs that assume a single trigger per compute, since one coalesced compute can now carry several changed dependencies. For example reportTransactionsAndViolations processes transactions or violations, never both:

App/src/libs/actions/OnyxDerived/configs/reportTransactionsAndViolations.ts

Lines 26 to 32 in 8f9ac4c

	if (transactionsUpdates) {
	transactionsToProcess = Object.keys(transactionsUpdates);
	} else if (transactionViolationsUpdates) {
	transactionsToProcess = Object.keys(transactionViolationsUpdates).map((transactionViolation) =>
	transactionViolation.replace(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS, ONYXKEYS.COLLECTION.TRANSACTION),
	);
	}

It should union the report keys from both updates. Similarly review reportAttributes (its sourceValues reads are already per-key so they mostly compose, but branches like the display-name reset in the else if (!sourceValues) path must stay correct) and sortedReportActions (its incremental branch keyed on reportActionsUpdates must also handle a coalesced REPORT/NETWORK trigger).

Consumers are unaffected: they read the derived key via useOnyx and simply receive one write per logical update instead of several, one macrotask later.

What alternative solutions did you explore? (Optional)

Coalescing with queueMicrotask instead of setTimeout — rejected because Onyx spreads the per-key broadcasts of one update across multiple microtasks, so a microtask flush would still run mid-update and not fully coalesce. Fixing it inside react-native-onyx (a single combined broadcast per Onyx.update) would be cleaner long-term but is a much larger library change affecting all subscribers.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

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

When a single logical Onyx update touches multiple dependencies of an OnyxDerived value (e.g. reportAttributes with 13 dependencies), each dependency's connection callback synchronously fires its own recompute of the derived value. Because Onyx delivers one logical write as several separate broadcasts across microtasks, N dependency changes produce N back-to-back full recomputes of the derived value, blocking the JS thread and dropping frames during app startup and report opens.

What is the root cause of that problem?

In src/libs/actions/OnyxDerived/index.ts, each dependency of a derived value is connected independently via Onyx.connect, and the callback calls recomputeDerivedValue inline (synchronously) with the single sourceValue from that one broadcast. There is no batching layer between the per-dependency broadcast and the compute invocation, so a logical write that touches K dependencies of a derived key produces K full computes of that derived value in the same microtask flush cycle rather than one.

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

1. In src/libs/actions/OnyxDerived/index.ts, replace the inline recompute in each dependency's Onyx.connect callback with an enqueue step: record {derivedKey, dependencyKey, dependencyIndex} in a pending set and, if no flush is scheduled, schedule flushRecompute via setTimeout(..., 0) so all broadcasts from the same logical update collapse into one macrotask.
2. Implement flushRecompute which, per pending derived key, builds the sourceValues array by (a) reading current snapshots from Onyx for all fired dependencies and (b) reconstructing per-collection deltas via a new shared getCollectionDelta(prevSnapshot, currentSnapshot) helper that leans on Onyx's structural-sharing reference equality to cheaply identify changed member keys. Non-collection deps pass their whole current value.
3. Add a per-derived-key baseline snapshot map captured at the end of each flush; the first flush has no baseline and computes from scratch (no sourceValues, full compute) — matching current cold-start semantics.
4. Update the three incremental configs that branched on "which single dependency changed" — src/libs/actions/OnyxDerived/configs/reportAttributes.ts, reportTransactionsAndViolations.ts, and sortedReportActions.ts — to iterate over ALL fired dependencies in the coalesced sourceValues rather than assuming exactly one.
5. Preserve init ordering with initOnyxDerivedValues in src/setup/index.ts: the pending-set/flush state must be module-scoped and created before any Onyx.connect callback can fire, so early broadcasts during startup are safely enqueued rather than dropped.
6. Add unit tests covering: (a) K dependency broadcasts in one tick → 1 compute call; (b) delta correctness for collection deps under structural sharing; (c) first-flush full-compute fallback; (d) incremental configs handle multi-dependency sourceValues.

What alternative solutions did you explore? (Optional)

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 17:16:51 UTC.

Proposal

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

OnyxDerived values recompute once per changed dependency instead of once per logical update. A single logical Onyx write that touches several dependencies of a derived value triggers one synchronous recompute per dependency, so a heavy derived value like reportAttributes (13 dependencies) recomputes many times back-to-back for one update, blocking the JS thread and dropping frames on startup and report opens.

What is the root cause of that problem?

In src/libs/actions/OnyxDerived/index.ts, each derived value opens one Onyx connection per dependency, and recomputeDerivedValue runs synchronously inside every connection callback:

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

Lines 109 to 118 in c8d6035

	if (OnyxKeys.isCollectionKey(dependencyOnyxKey)) {
	Onyx.connectWithoutView({
	key: dependencyOnyxKey,
	waitForCollectionCallback: true,
	callback: (value, collectionKey, sourceValue) => {
	Log.info(`[OnyxDerived] dependency ${collectionKey} for derived key ${key} changed, recomputing`);
	setDependencyValue(dependencyIndex, value as Parameters<typeof compute>[0][typeof dependencyIndex]);
	recomputeDerivedValue(dependencyOnyxKey, sourceValue, dependencyIndex);
	},
	});

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

Lines 139 to 149 in c8d6035

	} else {
	Onyx.connectWithoutView({
	key: dependencyOnyxKey,
	callback: (value) => {
	Log.info(`[OnyxDerived] dependency ${dependencyOnyxKey} for derived key ${key} changed, recomputing`);
	setDependencyValue(dependencyIndex, value as Parameters<typeof compute>[0][typeof dependencyIndex]);
	// if the dependency is not a collection, pass the entire value as the source value
	recomputeDerivedValue(dependencyOnyxKey, value, dependencyIndex);
	},
	});
	}

recomputeDerivedValue itself computes inline — there is no batching:

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

Lines 68 to 103 in c8d6035

	const recomputeDerivedValue = (sourceKey?: string, sourceValue?: unknown, triggeredByIndex?: number) => {
	// If this recompute was triggered by a connection callback, check if it initializes the connection
	if (!areAllConnectionsSet && triggeredByIndex !== undefined) {
	checkAndMarkConnectionInitialized(triggeredByIndex);
	}
	// Before all connections are established, don't write to Onyx.
	// This prevents overwriting a valid disk-cached value with empty defaults,
	// and avoids N-1 unnecessary Onyx writes during initialization.
	// We still update dependencyValues via setDependencyValue so data accumulates correctly.
	if (!areAllConnectionsSet) {
	Log.info(`[OnyxDerived] not all connections set for ${key}, deferring Onyx write`);
	return;
	}
	context.currentValue = derivedValue;
	context.sourceValues = sourceKey && sourceValue !== undefined ? {[sourceKey]: sourceValue} : undefined;
	const spanId = `${CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE}_${key}`;
	startSpan(spanId, {
	name: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	op: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	parentSpan: getSpan(CONST.TELEMETRY.SPAN_APP_STARTUP),
	attributes: {derivedKey: key},
	});
	try {
	// @ts-expect-error TypeScript can't confirm the shape of dependencyValues matches the compute function's parameters
	const newDerivedValue = compute(dependencyValues, context);
	Log.info(`[OnyxDerived] updating value for ${key} in Onyx`);
	derivedValue = newDerivedValue;
	setDerivedValue(key, derivedValue);
	} finally {
	endSpan(spanId);
	}
	};

Onyx delivers a single logical write (e.g. a ReconnectApp response touching reports, transactions and violations) as several separate broadcasts spread across microtasks, and each dependency is connected independently. So one logical update fires N dependency callbacks, each running a full synchronous compute. reportAttributes declares 13 dependencies and is among the heaviest computes:

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 86 to 101 in c8d6035

	dependencies: [
	ONYXKEYS.COLLECTION.REPORT,
	ONYXKEYS.NVP_PREFERRED_LOCALE,
	ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS,
	ONYXKEYS.COLLECTION.REPORT_ACTIONS,
	ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS,
	ONYXKEYS.COLLECTION.TRANSACTION,
	ONYXKEYS.PERSONAL_DETAILS_LIST,
	ONYXKEYS.SESSION,
	ONYXKEYS.COLLECTION.POLICY,
	ONYXKEYS.COLLECTION.POLICY_TAGS,
	ONYXKEYS.CONCIERGE_REPORT_ID,
	ONYXKEYS.NVP_INTRO_SELECTED,
	ONYXKEYS.COLLECTION.REPORT_METADATA,
	ONYXKEYS.NETWORK,
	],

On a heavy account it fired ~14×/run — a 123 + 105 + 101 + 75 ≈ 404 ms burst — for what is logically one update.

Two secondary constraints make a naive fix insufficient:

• context.sourceValues is built from a single per-broadcast sourceValue, and sourceValue is a mechanism being phased out — it can't carry the merged delta of a coalesced flush:

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

  Lines 83 to 84 in c8d6035

  	context.currentValue = derivedValue;
  	context.sourceValues = sourceKey && sourceValue !== undefined ? {[sourceKey]: sourceValue} : undefined;

• The incremental configs read the changed-member delta straight out of sourceValues (e.g. reportAttributes reads each collection's slice independently), so they must keep receiving an accurate per-key delta after coalescing or they silently skip work / go stale:

  App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 176 to 182 in c8d6035

  	const reportUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT] ?? {};
  	const reportMetadataUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_METADATA] ?? {};
  	const reportActionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_ACTIONS] ?? {};
  	const reportNameValuePairsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS] ?? {};
  	const transactionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION];
  	const transactionViolationsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS];
  	const policyTagsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.POLICY_TAGS];

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

Coalesce the per-dependency callbacks of each derived value into one macrotask flush, and reconstruct the changed-member delta at flush time.

1. Coalesce. recomputeDerivedValue stops computing inline. Each callback records its dependencyIndex into a per-key pendingIndices set (still calling setDependencyValue so dependencyValues stays current) and schedules a single flush:

pendingIndices.add(dependencyIndex);
if (!isFlushScheduled) {
    isFlushScheduled = true;
    setTimeout(flushRecompute, 0);
}

Every callback from the same logical update lands in that one pending flush, collapsing N recomputes to 1. The existing areAllConnectionsSet gating and the telemetry span move into flushRecompute.

2. Reconstruct the delta at flush time. Instead of Onyx's per-broadcast sourceValue, flushRecompute rebuilds sourceValues itself. For each collection dependency in pendingIndices, a new shared getCollectionDelta(current, baseline) helper diffs the current collection snapshot against a baseline captured at the previous flush. Because Onyx structurally shares unchanged members, this is a cheap reference scan that returns exactly the changed members — the same Partial<Collection> shape the configs already consume. Non-collection dependencies pass their whole value. The first flush has no baselines → sourceValues is undefined → full compute, and it captures the initial baselines. After computing, it snapshots the current collections as the next baselines and clears pendingIndices / isFlushScheduled.

3. Feed every coalesced trigger to the configs. Because a flush can now carry several changed collections at once, sourceValues must contain the delta for all of them, and each incremental config must consume every key present rather than assuming one. reportAttributes already reads each key independently (sourceValues?.[COLLECTION.REPORT], [COLLECTION.TRANSACTION], …) so it composes naturally; reportTransactionsAndViolations and sortedReportActions are audited the same way so no branch is skipped when multiple deps coalesce.

Net effect: one logical update produces exactly one compute of each derived value. Derived values become eventually consistent within one macrotask of the originating write, and useOnyx consumers re-render normally when the single updated value lands (Recomputes 62 → 19, −69%; ManualSendMessage 168 → 84 ms, −50%; startup unchanged).

What specific scenarios should we cover in automated tests to prevent this problem from happening again?

• Multi-dependency coalescing: a mergeCollection touching REPORT + TRANSACTION + TRANSACTION_VIOLATIONS in one logical update results in the derived compute running exactly once (spy on the compute / assert a single setDerivedValue), not once per collection.
• Delta correctness: getCollectionDelta returns only the members whose reference changed between two snapshots, and an unchanged collection yields an empty delta (no wasted iteration).
• Incremental correctness after coalescing: a coalesced flush carrying both report and transaction changes updates the attributes for reports affected by either — no changed key is dropped when several arrive together.
• Eventual consistency: after the writes settle (one macrotask), the derived Onyx value equals a from-scratch full recompute of the same inputs.
• First-flush path: with no baselines, the initial flush computes from scratch (sourceValues undefined) and seeds baselines for subsequent diffs.

What alternative solutions did you explore? (Optional)

Flushing on a microtask (queueMicrotask / Promise.resolve().then) instead of setTimeout(0). Onyx spreads one logical write across multiple microtasks, so a microtask flush drains between broadcasts and still splits the update into several computes; a macrotask reliably lands after all of that update's broadcasts, which is what collapses them to one.

I also considered keeping Onyx's sourceValue and merging the N payloads into one delta. But sourceValue is being phased out, and merging partial payloads is exactly what breaks under coalescing — reconstructing the delta from baselines via structural sharing is self-contained and forward-compatible.