Stop deep-comparing the full transaction history per check in `selectLocalTransactions`

[MajorLift]

Performance audit finding · Severity: High · Effort: Medium · Fix risk: Moderate · Test safety net: Partial
Owner: CODEOWNERS best-effort (transactions)
File: app/selectors/transactionController.ts:247

What is this about?

selectLocalTransactions is a createDeepEqualSelector over a pipeline that allocates aggressively upstream: selectNonReplacedTransactions spreads and sorts the merged transaction + pending-smart-transaction arrays on every recompute (transactionController.ts:240 area), and the result function filters the full list again. Because the wrapper is deep-equal, its inputs are deep-compared on every check — for a power-user transaction history (~2,000 entries) that is an O(n) structural comparison of large transaction objects per consumer per flush, on top of the spread+sort chains re-running on every TransactionController state change.

Why it matters

The transaction list is a primary power-user surface; this pipeline runs its compares a few times per second (250ms batched flush) for as long as the activity view is mounted, with cost proportional to history size. None of the 2026-06-09 audit-run issues cover it (#31354/#31355 cover the adjacent Map/Set allocations only).

Scenario

N/A — see Technical Details.

Design

N/A — internal performance change; no UI/design impact.

Technical Details

Fix direction

1. Establish the reference-stability contract of the inputs: TransactionController state arrives via the engine slice (per-controller key replace, Immer structural sharing), so the raw transactions array reference changes only when transactions actually change. If so, the deep-equal wrapper is paying for stability the store already provides — narrow the inputs and downgrade toward plain createSelector.
2. Move the dedupe/sort/filter into one memoized step keyed on the raw transactions input rather than re-running per layer, so the chain recomputes once per actual data change.
3. If consumers need stability across genuinely-churning inputs, prefer a resultEqualityCheck on the (much smaller) output over deep-comparing the full input arrays.

Threat Modeling Framework

N/A — performance-only change; behavior is preserved, no new data flow / trust boundary / attack surface.

Acceptance Criteria

• Recompute count ~1 per actual transaction change (not per flush); no full-array deep compares per check on the hot path.
• Profiler on a power-user profile (~2,000 tx): activity view render time and JS-thread time during balance-poll flushes drop measurably.
• Reassure perf-test on the transactions view locks the win in CI.

References

• Files: app/selectors/transactionController.ts:247 (and the upstream selectNonReplacedTransactions / sorted-transactions chain)
• Related (already filed): Memoize new Map result in selectRelatedChainIdsByTransactionId #31354, Memoize new Set result in selectRequiredTransactionIds #31355
• Source: mms-performance per-selector triage (perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49, mm-selector-cascade — deep-equal selectors pay O(input) per check)
• Status: UNVALIDATED (static evidence; needs profiler confirmation)

[metamask-ci]

Triage Agent -- Classification

Severity: Sev2 (confidence: 0.88) ✅

This is a performance issue affecting power users with large transaction histories (~2,000 entries). The activity view becomes slow and JS-thread CPU usage spikes during balance-poll flushes. It doesn't cause crashes or data loss, but significantly degrades the user experience for a subset of users. A workaround exists (having fewer transactions), but it's not practical.

Size: size-M (confidence: 0.82) ⚠️ Advisory

The fix requires refactoring multiple selectors across at least two files (transactionController.ts and smartTransactionsController.ts). The core issue is the selector memoization strategy — replacing createDeepEqualSelector with more efficient approaches (e.g., structural sharing, ID-based comparison, or breaking the selector chain). This requires careful investigation of all downstream consumers and testing with large datasets. Estimated 1-3 days.
Not auto-applied -- confidence below threshold.

Team: team-transactions ✅

Matched via area fallback: area-transactions (no CODEOWNERS match)

---

Root Cause Analysis

Affected component: Transaction selectors in app/selectors/transactionController.ts and app/selectors/smartTransactionsController.ts

The selector chain starting from selectTransactionsStrict through selectNonReplacedTransactions, selectSortedTransactions, and selectLocalTransactions uses createDeepEqualSelector extensively. Each selector in the chain creates new arrays via .filter(), spread operators ([...]), and .sort() on every recompute, which means the deep-equal comparison must traverse the entire array of ~2,000 TransactionMeta objects to determine if the output changed. Specifically:

1. selectNonReplacedTransactions filters transactions and wraps with createDeepEqualSelector — every state change triggers a filter that produces a new array reference, forcing a deep comparison of all ~2,000 items.
2. selectLocalTransactions depends on selectNonReplacedTransactions and selectPendingSmartTransactionsForSelectedAccountGroup, spreads them together, runs dedupeTransactions, and sorts — all producing new array references that trigger another full deep comparison.
3. selectPendingSmartTransactionsBySender and selectPendingSmartTransactionsForSelectedAccountGroup also use createDeepEqualSelector with .filter() and .map() that create new objects via spread.
4. During balance-poll flushes (every 250ms), the TransactionController state reference changes even if transactions haven't actually changed, triggering the entire selector chain to recompute and deep-compare.

Evidence:

• selectNonReplacedTransactions uses createDeepEqualSelector with .filter() creating new arrays
• selectLocalTransactions spreads, dedupes, and sorts arrays on every recompute before deep comparison
• selectSortedTransactions spreads and sorts merged arrays with createDeepEqualSelector
• selectPendingSmartTransactionsBySender maps with spread operator creating new objects
• All these selectors use createDeepEqualSelector which performs O(n) structural comparison on TransactionMeta objects
• Balance-poll flushes at 250ms intervals trigger state changes that cascade through the selector chain

Suggested Fix

Confidence: high: clear from code context — the selector chain and its use of createDeepEqualSelector with array-creating operations is directly visible in the provided code

Refactor the selector chain to minimize deep-equal comparisons on large arrays. The key strategies are: (1) Use lightweight identity checks where possible instead of deep equality, (2) Add an intermediate selector that extracts a stable fingerprint (e.g., transaction IDs + statuses hash) to short-circuit expensive recomputation, (3) Avoid creating new arrays/objects in intermediate selectors when the underlying data hasn't changed.

Target files: app/selectors/transactionController.ts, app/selectors/smartTransactionsController.ts
Target functions: selectNonReplacedTransactions, selectLocalTransactions, selectSortedTransactions, selectSortedEVMTransactionsForSelectedAccountGroup, selectPendingSmartTransactionsBySender, selectPendingSmartTransactionsForSelectedAccountGroup

Approach:

1. Add a fingerprint selector before selectNonReplacedTransactions: Create a selector that computes a lightweight fingerprint of the transactions array (e.g., transactions.map(tx => tx.id + tx.status + tx.replacedBy).join(',')). Use this as an input to selectNonReplacedTransactions so it only recomputes when the fingerprint changes.

2. Replace createDeepEqualSelector with createSelector for intermediate selectors (selectNonReplacedTransactions, selectSortedTransactions) that feed into other selectors. Only use createDeepEqualSelector at the leaf selectors that directly feed React components.

3. For selectLocalTransactions, consider using a two-phase approach: first compute a stable set of transaction IDs that should be included (cheap comparison), then only rebuild the full array when the ID set changes.

4. For selectPendingSmartTransactionsBySender/ForSelectedAccountGroup, avoid .map() with spread that creates new objects on every recompute. Instead, memoize the mapping separately or use a WeakMap cache.

5. Alternative simpler approach: Replace the deep-equal result comparator in the hot-path selectors with a custom comparator that only checks array length + a few key fields (id, status, hash) rather than full structural equality. This can be done by passing a custom memoizeOptions.resultEqualityCheck to createSelector.

6. Consider pagination: For the activity view, only select the first N transactions needed for the visible viewport rather than the full history.

---

Confidence threshold: 0.85. Labels marked ✅ were auto-applied. Labels marked ⚠️ are advisory only (below threshold).
To re-triage, remove the ta-bot-triage label and re-apply ta-needs-triage.
⚠️ Some dimensions could not be confidently classified. An engineer should review this issue.