[Due for payment 2026-07-17] [$250] NewDot web tab crashes silently (renderer OOM kill) under high memory / large Onyx dataset

[melvin-bot]

Problem

NewDot's browser tab crashes repeatedly and silently on web. The crash produces no JS error, runs no graceful shutdown, and Sentry captures zero error events. It has been reproduced regularly on staging and on ad-hoc builds while doing normal activity (DMing other users, clicking around inside an expense on the Spend page, etc.).

Root cause (current best understanding)

Renderer process OOM kill. The browser/OS SIGKILLs the renderer process under physical RAM pressure. This happens below jsHeapSizeLimit, so it is completely independent of the V8 heap limit and produces no JS error — which is why nothing reaches Sentry through normal error reporting.

Evidence from crash tracking captured via the instrumentation PRs below:

• JS heap chronically pinned at ~97–98% usage with a large retained live set (~1.1 GB in one session, ~3.5 GB in a later one). The set is genuinely retained — a GC ran between two snapshots yet couldn't drop below ~1.1 GB.
• A later crash report: usedJSHeapSizeMB: 3572, totalJSHeapSizeMB: 3589, jsHeapSizeLimitMB: 4192, reportsCount: 1083, domNodes: 2430, visibility: hidden.
• Earlier memory snapshots before a crash: 98.13% and 97.38% heap usage with only ~23–29 MB free.

The trigger

The crash typically follows a healthy ManualSendMessage (the send itself renders fine in ~100 ms), then dies ~1 s later while draining post-send work. In one ~1.23 s window a single comment generated:

• 71 Onyx writes (21 of them snapshot_ blobs — the AddComment snapshot fan-out)
• 27 OnyxDerived recomputes, including reportAttributes ×6 and todos ×6, each iterating all ~89 reports.

With only ~23–29 MB free, that allocation burst is the final straw → OOM kill. Bursts of OnyxDerived recomputation (e.g. 91 computation events at once) were observed correlating with crashes, also triggered by OpenApp.

Proposed action items

• Investigate the high retained heap — large memory footprint even for a normal number of reports. Find what's keeping ~1.1 GB+ resident.
• Upgrade the OnyxDerived system to batch/debounce computation when many dependencies change in the same time window (would help many other cases too).
• Cut the snapshot fan-out — does one comment really need to rewrite ~21 search snapshots?
• Continue crash instrumentation so renderer OOM kills are observable.

Related work

• [No QA] Add Sentry ReportingObserver integration to capture browser crash/intervention reports #93049 — ReportingObserver / Reporting API instrumentation
• [TESTING] Add web crash diagnostics to detect abnormal browser session exits #93264 — crash + memory tracking PR (this successfully caught a reproduced crash and reported it to Sentry)
• Sentry issue: 7543552932

Reported in Slack.

Issue Owner

Current Issue Owner: @eh2077

Issue Owner

Current Issue Owner: @eh2077

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067540022852060482
• Upwork Job ID: 2067540022852060482
• Last Price Increase: 2026-06-18

[MelvinBot]

Issue Analysis

Confidence: High for the trigger mechanism, Medium for the dominant retained-heap source (needs a heap snapshot to settle which holds the GBs).

Root cause confirmed: The crash is a renderer OOM, and the code matches the hypothesis. Two App-side problems amplify every "drain post-send" burst, and a third is purely backend.

1. OnyxDerived has no batching/debouncing — every dependency write recomputes synchronously (App-fixable ✅)

The engine wires one Onyx.connectWithoutView per dependency, and each callback immediately recomputes and writes — there is no queue, timer, or microtask coalescing:

• OnyxDerived/index.ts:64-99 — recomputeDerivedValue runs compute() and writes synchronously on every callback (index.ts:109-112).
• OnyxDerived/utils.ts:23-26 — each recompute writes with skipCacheCheck: true, so there's no deep-equality short-circuit; every write notifies all useOnyx subscribers and allocates a fresh object.

reportAttributes (13 deps) and todos (9 deps) both subscribe to the overlapping report collections (report_, reportActions_, reportMetadata_, transaction_, reportNVP_, policy_). A comment send mutates ~6 of those collections twice (optimistic + server), so each derived key recomputes ~6× — exactly the observed reportAttributes ×6 / todos ×6.

todos.ts:38-86 always does a full O(all reports) scan with 4 expensive predicates per expense report — no incremental path. reportAttributes has an incremental fast-path but still runs an unconditional all-reports loop every time (reportAttributes.ts:378-396).

2. The Onyx cache is never bounded by JS-heap pressure (App-fixable ✅)

evictableKeys includes SNAPSHOT and REPORT_ACTIONS (setup/index.ts:37-43), but eviction in react-native-onyx only fires on a persistent-storage quota error, never on RAM pressure. On web/IndexedDB the disk quota is huge, so it effectively never fires and the in-memory storageMap grows unbounded. Two specific App-side retainers stand out:

• sortedReportActions (configs/sortedReportActions.ts:40-112) builds a full second copy of every report's actions and is keyed RAM_ONLY_…, so it is never evicted (setup/index.ts:63). This roughly doubles the report-actions footprint — large for accounts with deep chat history even at 89 reports.
• snapshot_ blobs are denormalized SearchResults copies that accumulate one-per-search with no proactive cleanup, and several screens subscribe to the whole SNAPSHOT collection (e.g. SplitExpensePage, useDeleteTransactions), pinning all of them resident.

3. Snapshot fan-out (~21 snapshot_ writes per comment) is backend-driven — escalate ⚠️

The App optimistic path writes only one snapshot (the canned CHAT query) — Report/index.ts:1000-1004. The remaining ~20 arrive in the AddComment server response's onyxData/Pusher. This fan-out cannot be reduced from App — the logic that enumerates which search snapshots get the new report lives in the backend (Web-Expensify/Auth). This needs an internal engineer; the question to answer there is whether AddComment should fan out into every cached snapshot and whether it sends full blobs vs. minimal merges.

---

Recommended actions (re-prioritized)

The single highest-leverage App-side fix is #1 — it cuts both CPU and the allocation burst that is "the final straw," and helps OpenApp and every other multi-write flow:

1. Batch/debounce OnyxDerived recompute. Coalesce same-tick dependency callbacks into one recompute per derived key (microtask/InteractionManager flush), and/or add an equality check before Onyx.set so unchanged results don't notify subscribers.
2. Make todos incremental like reportAttributes, scoping work to changed report keys instead of re-scanning all reports every callback.
3. Bound memory under heap pressure — add a heap-aware eviction trigger (or cap resident snapshot_ count / give snapshots a TTL and clear on navigating away from Search), and reconsider whether sortedReportActions must hold every report's actions in RAM permanently.
4. Escalate the snapshot fan-out (Add Expensify eslint #3 above) to a backend engineer — not actionable in App.
5. Keep the crash instrumentation from [TESTING] Add web crash diagnostics to detect abnormal browser session exits #93264 running to observe renderer OOM kills.

Evidence chain & open questions

• Trigger: healthy ManualSendMessage → ~6 report collections written twice (optimistic + server) → each fires reportAttributes/todos recompute with no coalescing → full all-reports scans + fresh allocations under ~23–29 MB free → OOM ~1s later. High confidence; the ×6 counts and timing match the code exactly.
• Retained heap (medium confidence): a Chrome heap-snapshot "retainers" view on the OOM'd tab would settle which dominates — Onyx storageMap snapshots vs. the sortedReportActions RAM-only copy vs. other derived maps. The existing SPAN_ONYX_DERIVED_COMPUTE spans + the [OnyxDerived] dependency X changed, recomputing logs can confirm the 27-recompute count and per-compute duration/collection size in production.
• Alternative considered: could the burst be a useOnyx re-render storm rather than derived compute? The skipCacheCheck: true writes do force subscriber notifications, so Some initial fixes and code style updates #1's equality-check half also addresses that — they're complementary, not competing.
• Backend AddComment handler (private): does it skip snapshots that aren't currently mounted/subscribed, and does it send full blobs or merges?

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93916) to create a draft PR (recommend scoping the first PR to action item #1 only — OnyxDerived batching).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[lorretheboy]

Proposal

What is the root cause of that problem?

The OnyxDerived engine recomputes synchronously, once per triggering collection, with no coalescing — so a single user action that writes many keys forces many full recomputes back‑to‑back, and the resulting allocation burst is what tips an already‑saturated renderer over into an OOM SIGKILL.

In the shared init loop each dependency is wired as its own Onyx.connectWithoutView callback that calls recomputeDerivedValue immediately and synchronously:

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

Lines 101 to 146 in 86d13c5

	for (let i = 0; i < dependencies.length; i++) {
	const dependencyIndex = i;
	const dependencyOnyxKey = dependencies[dependencyIndex];
	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);
	},
	});
	} else if (dependencyOnyxKey === ONYXKEYS.NVP_PREFERRED_LOCALE) {
	// Special case for locale, we want to recompute derived values when the locale change actually loads.
	Onyx.connectWithoutView({
	key: ONYXKEYS.RAM_ONLY_ARE_TRANSLATIONS_LOADING,
	callback: (value) => {
	if (value ?? true) {
	Log.info(`[OnyxDerived] translations are still loading, not recomputing derived value for ${key}`);
	return;
	}
	Log.info(`[OnyxDerived] translations loaded, recomputing derived value for ${key}`);
	const localeValue = IntlStore.getCurrentLocale();
	if (!localeValue) {
	Log.info(`[OnyxDerived] No locale found for derived key ${key}, skipping recompute`);
	return;
	}
	Log.info(`[OnyxDerived] dependency ${dependencyOnyxKey} for derived key ${key} changed, recomputing`);
	setDependencyValue(dependencyIndex, localeValue as Parameters<typeof compute>[0][typeof dependencyIndex]);
	recomputeDerivedValue(dependencyOnyxKey, localeValue, dependencyIndex);
	},
	});
	} 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);
	},
	});
	}
	}

So when sending a comment fans out into ~71 Onyx writes touching report, reportActions, snapshot_, etc. within one window, every derived value that lists those collections recomputes once per collection that changed (the reported reportAttributes ×6, todos ×6). There is no batching of writes that land in the same tick:

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

Lines 64 to 99 in 86d13c5

	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);
	}
	};

Each of those recomputes allocates over the full report set. todos has no incremental path at all — every call rescans every report and rebuilds all the result arrays from scratch:

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

Lines 52 to 86 in 86d13c5

	for (const report of reports) {
	if (!report?.reportID || report.type !== CONST.REPORT.TYPE.EXPENSE) {
	continue;
	}
	const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const reportNameValuePair = allReportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.chatReportID}`];
	const reportActions = Object.values(allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.reportID}`] ?? []);
	const reportTransactions = transactionsByReportID[report.reportID] ?? [];
	const reportMetadata = allReportMetadata?.[`${ONYXKEYS.COLLECTION.REPORT_METADATA}${report.reportID}`];
	const allExpensesHeld = hasOnlyHeldExpenses(reportTransactions);
	if (isSubmitAction(report, reportTransactions, reportMetadata, policy, reportNameValuePair, undefined, login, currentUserAccountID) && !allExpensesHeld) {
	reportsToSubmit.push(report);
	}
	if (isApproveAction(report, reportTransactions, currentUserAccountID, reportMetadata, policy) && !allExpensesHeld) {
	reportsToApprove.push(report);
	}
	if (
	isPrimaryPayAction({
	report,
	reportTransactions,
	currentUserAccountID,
	currentUserLogin: login,
	bankAccountList,
	policy,
	reportNameValuePairs: reportNameValuePair,
	}) &&
	!hasOnlyNonReimbursableTransactions(report.reportID, reportTransactions) &&
	!allExpensesHeld
	) {
	reportsToPay.push(report);
	}
	if (isExportAction(report, login, policy, reportActions) && policy?.exporter === login) {
	reportsToExport.push(report);
	}
	}

and reportAttributes, even on an incremental update of one report, shallow‑clones the entire attributes map for all ~89 reports as the reducer seed:

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

Lines 260 to 374 in 86d13c5

	const reportAttributes = dataToIterate.reduce<ReportAttributesDerivedValue['reports']>(
	(acc, key) => {
	// source value sends partial data, so we need an entire report object to do computations
	const report = reports[key];
	if (!report || !isValidReport(report)) {
	const reportID = key.replace(ONYXKEYS.COLLECTION.REPORT, '');
	if (acc[reportID]) {
	delete acc[reportID];
	}
	return acc;
	}
	const chatReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.chatReportID}`];
	const reportNameValuePair = reportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`];
	const reportActionsList = reportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.reportID}`];
	const isReportArchived = isArchivedReport(reportNameValuePair);
	const {
	hasAnyViolations,
	requiresAttention,
	reportErrors,
	oneTransactionThreadReportID,
	actionBadge: actionGreenBadge,
	actionTargetReportActionID: actionGreenTargetReportActionID,
	} = generateReportAttributes({
	report,
	chatReport,
	reportActions,
	transactionViolations,
	isReportArchived,
	allTransactions: transactions,
	reports,
	currentUserAccountID: session?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin: session?.email ?? '',
	});
	const policy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const hasFieldViolations = hasVisibleReportFieldViolations(report, policy, session?.accountID);
	let brickRoadStatus;
	let actionBadge;
	let actionTargetReportActionID;
	let needsParentChatErrorPropagation = false;
	const reasonAndReportAction = SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad(
	report,
	chatReport,
	reportActionsList,
	hasAnyViolations || hasFieldViolations,
	reportErrors,
	transactions,
	isOffline,
	transactionViolations,
	!!isReportArchived,
	reports,
	);
	// When the report is ready to submit, always show the green Submit badge
	// regardless of violations — the user can submit without fix.
	const willShowGreenSubmit = requiresAttention && actionGreenBadge === CONST.REPORT.ACTION_BADGE.SUBMIT;
	// if report has errors or violations, show red dot
	// Also skip setting ERROR when we'll show the green Submit badge — let the user submit without fix.
	if (reasonAndReportAction && !willShowGreenSubmit) {
	needsParentChatErrorPropagation = true;
	// RBR/Fix mirrors GBR's access rule: only show on the child when the user can't already
	// see it on the parent workspace chat. The parent still gets ERROR/FIX through the
	// propagation loop below, so the actionable indicator surfaces on the workspace chat row
	// (which is where C+ wants it). Skips when the chat parent isn't accessible to the user.
	const chatPolicy = chatReport?.policyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${chatReport.policyID}`] : undefined;
	const isChildOfAccessiblePolicyExpenseChat = !!chatReport && isPolicyExpenseChat(chatReport) && (!!chatReport.isOwnPolicyExpenseChat || isPolicyAdmin(chatPolicy));
	if (!isChildOfAccessiblePolicyExpenseChat) {
	brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR;
	actionBadge = CONST.REPORT.ACTION_BADGE.FIX;
	actionTargetReportActionID = reasonAndReportAction.reportAction?.reportActionID;
	}
	}
	// if report does not have error, check if it should show green dot
	if (brickRoadStatus !== CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR && requiresAttention) {
	brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.INFO;
	actionBadge = actionGreenBadge;
	actionTargetReportActionID = actionGreenTargetReportActionID;
	}
	acc[report.reportID] = {
	reportName: report
	? computeReportName({
	report,
	reports,
	policies,
	transactions,
	allReportNameValuePairs: reportNameValuePairs,
	personalDetailsList: personalDetails,
	reportActions,
	currentUserAccountID: session?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin: session?.email ?? '',
	allPolicyTags: policyTags,
	conciergeReportID: conciergeReportID ?? undefined,
	reportAttributes: currentValue?.reports,
	})
	: '',
	isEmpty: generateIsEmptyReport(report, isReportArchived),
	brickRoadStatus,
	requiresAttention,
	actionBadge,
	actionTargetReportActionID,
	reportErrors,
	oneTransactionThreadReportID,
	needsParentChatErrorPropagation,
	};
	return acc;
	},
	currentValue?.reports ? {...currentValue.reports} : {},
	);

Causal chain: one action → batched multi‑collection writes → N un‑coalesced recompute callbacks → N full‑report allocations (clones + array rebuilds) in a tight window → with the heap pinned at ~97–98% and only ~23–29 MB free, that burst exceeds physical RAM → renderer killed below jsHeapSizeLimit, no JS error, nothing reaches Sentry.

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

Coalesce recomputes at the single convergence point — the init loop in OnyxDerived/index.ts. Instead of each callback calling recomputeDerivedValue synchronously, have the callbacks update dependencyValues, accumulate the sourceValues (merging per source collection so incremental configs still see every changed key), and schedule one recompute per derived key via a microtask/short debounce that runs once after the current Onyx batch drains.

This collapses the ×6 recomputes seen for reportAttributes and todos into a single pass with a single merged sourceValues, so a burst of writes produces one allocation over the report set instead of one per collection. It changes nothing about correctness (the merged sourceValues carry the same changed keys the incremental logic already consumes here:

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

Lines 78 to 98 in 86d13c5

	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);
	}

) and directly removes the per‑burst allocation amplification that triggers the OOM kill. It also helps OpenApp and other multi‑key bursts noted in the report.

What alternative solutions did you explore? (Optional)

Attack the per‑recompute allocation size instead of the frequency: give todos an incremental path so it only re‑evaluates reports whose keys changed, and avoid cloning the whole currentValue.reports map for incremental reportAttributes runs. Separately, trim the search‑snapshot fan‑out so routine writes don’t rewrite many snapshot_ blobs. These shrink each burst but, unlike coalescing, don’t stop N independent recomputes from firing for one action, so they’re best layered on top of the batching fix rather than instead of it.

[ahmdshrif]

Proposal

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

NewDot's web tab is SIGKILLed by the OS as a renderer OOM — below jsHeapSizeLimit, so there's no JS error and nothing reaches Sentry. It dies ~1s after a normal action (e.g. sending a comment) while draining post-send work.

What is the root cause of that problem?

The proximate, frontend-fixable cause is that OnyxDerived has no recompute coalescing — every individual Onyx write synchronously drives a full derived recompute, so a normal write burst becomes an allocation storm.

1. The driver runs recomputeDerivedValue synchronously inside each Onyx callback (collection, locale, scalar) with no microtask/debounce between writes: index.ts#L64-L143.
2. todos rescans all reports per recompute with no incremental scoping (todos.ts#L38-L86); reportAttributes already scopes by sourceValues (reportAttributes.ts#L147-L190) — todos is the asymmetric amplifier.

So one comment's 71 Onyx writes fan into 27 recomputes (todos ×6, reportAttributes ×6), each iterating ~89 reports in 1.23s. With only ~25MB free that transient burst exceeds free RAM → renderer killed below the V8 limit → no JS error. Explains every symptom incl. trigger timing and the missing Sentry event.

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

Coalesce recomputes at the single chokepoint: in recomputeDerivedValue, accumulate changed sourceValues per key and flush once per microtask (queueMicrotask) instead of per callback. One central change covers all 11 configs and collapses a burst to one recompute per key. Also give todos the sourceValues incremental scoping reportAttributes already has.
Regression-safe: the flush still settles within the same tick before paint and merges every accumulated sourceValue, so consumers see identical final values — only the count of intermediate recomputes drops.

What alternative solutions did you explore? (Optional)

• Cut the snapshot fan-out: fewer writes, but REPORT/REPORT_ACTIONS writes still storm the derived layer — partial mitigation.
• Bound the retained ~1.1GB heap (cache cap): necessary but separate and not localizable to one PR; the un-coalesced burst still spikes allocations.
• Debounce only todos: too narrow — the other 10 configs keep recomputing per write.

[melvin-bot]

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

[melvin-bot]

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