Add cancellation (`AbortController` / cancelled flag) to async effects that `setState` after resolve

[MajorLift]

Performance audit finding · Severity: Medium (batch) · Effort: Medium · Fix risk: Simple · Test safety net: Partial
Owner: per-file CODEOWNERS
Scope: 16 sweep hits app-wide

What is this about?

Async effects that fetch(...)/.then(...) and set state on resolve, with no cancelled flag or AbortController, keep running after unmount (wasted work, "setState on unmounted component") and race when the driving input changes quickly (stale response overwrites fresh data). Sweep on main (b3e7eb88) found 16 candidate sites. Verified instances:

• app/components/Views/ConnectQRHardware/index.tsx:129 — KeyringController.getAccounts().then(...)
• app/components/Views/LedgerSelectAccount/index.tsx:135 and :210
• app/components/Views/RevealPrivateCredential/RevealPrivateCredential.tsx:139
• remaining 12 hits: re-run the detection recipe and triage (some may be guarded upstream)

Detection recipe:
grep -rn -A6 "useEffect(" app --include="*.ts" --include="*.tsx" | grep -E "fetch\(|\.then\(" | grep -v "signal\|cancelled\|abort" | grep -v ".test."

Technical Details

Extract shared hooks (useIsMounted, useAbortableEffect) so cleanup is default.

Fix per site: cancelled-flag cleanup (cheapest, works for any promise) or AbortController (also cancels the request; RN fetch supports signal).

Acceptance Criteria

• All 16 hits triaged: fixed or waived with a stated reason (e.g. app-lifetime component).
• No "setState on unmounted component" warnings when rapidly entering/leaving the affected screens.

References

• Source: mms-performance sweep recipes added in perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49 (mm-useeffect-antipatterns)
• Status: UNVALIDATED per instance (static sweep)

[mm-token-exchange-service]

Triage Agent -- Classification

Severity: Sev2 (confidence: 0.85) ✅

These are async effects that setState after unmount, causing React warnings, wasted network requests, and potential race conditions where stale data overwrites fresh data. While not causing crashes or fund loss, they degrade performance and can lead to incorrect UI state across multiple screens (ConnectQRHardware, LedgerSelectAccount, RevealPrivateCredential, etc.). Workarounds exist (users can wait for screens to load before navigating away), but the issue affects multiple flows.

Size: size-L (confidence: 0.85) ✅

16 async effects across multiple components need to be patched. The issue also calls for extracting shared hooks (useIsMounted, useAbortableEffect) after initial manual implementations. This is a cross-component change touching many files, requiring investigation of each site to determine the correct cancellation pattern (AbortController for fetch calls, cancelled flag for promise chains). Estimated 3-5 days.

Team: team-accounts ✅

Matched via CODEOWNERS: @MetaMask/accounts-engineers

---

Root Cause Analysis

Affected component: Multiple React components with async useEffect hooks (ConnectQRHardware, LedgerSelectAccount, RevealPrivateCredential, and 13+ others)

Across 16 sites in the codebase, useEffect hooks initiate async operations (fetch calls, promise chains) and call setState in the .then() or after await, without checking whether the component is still mounted. When a user navigates away before the async operation completes, the resolved promise still attempts to update state on an unmounted component. Additionally, when inputs change rapidly (e.g., typing in a search field), multiple concurrent requests can race, and a slower earlier request can resolve after a faster later request, overwriting the correct (fresh) data with stale data. The existing hook library (usePolling, useDebouncedValue, usePrevious) does not include a useIsMounted or useAbortableEffect utility, so each component would need to manually implement cancellation until shared hooks are extracted.

Evidence:

• grep recipe identifies 16 async effects with fetch/.then without signal/cancelled/abort guards
• 'setState on unmounted component' warnings observed in console
• Screens mentioned: ConnectQRHardware, LedgerSelectAccount, RevealPrivateCredential
• KeyringController mentioned as a controller involved in affected flows
• Existing hooks (usePolling, useDebouncedValue, usePrevious) lack cancellation patterns

Suggested Fix

Confidence: medium: likely but needs investigation - the pattern is clear but exact file paths for all 16 sites need to be discovered via the grep recipe

For each of the 16 identified async effects: add a cancellation mechanism (either a cancelled boolean flag checked before setState, or pass an AbortController signal to fetch calls). After manually fixing 3 sites, extract shared hooks useIsMounted and useAbortableEffect into the common hooks directory and refactor remaining sites to use them.

Target files: app/components/hooks/useIsMounted.ts (new file), app/components/hooks/useAbortableEffect.ts (new file)
Target functions: useIsMounted (new hook returning a ref that tracks mount status), useAbortableEffect (new hook wrapping useEffect with AbortController lifecycle)

Approach:

1. Create useIsMounted hook: returns a useRef(true) that is set to false in the useEffect cleanup. Components check isMounted.current before calling setState. 2. Create useAbortableEffect hook: wraps useEffect, creates an AbortController on each invocation, passes signal to the effect callback, and calls controller.abort() in cleanup. 3. For each of the 16 identified sites, apply the pattern: (a) For fetch-based effects, use useAbortableEffect and pass signal to fetch options. (b) For non-fetch async effects (e.g., KeyringController calls), use a let cancelled = false flag in the effect body, check if (!cancelled) before setState, and set cancelled = true in cleanup. 4. Search for affected files using the grep recipe: grep -rn -A6 'useEffect(' app --include='*.ts' --include='*.tsx' | grep -E 'fetch\(|.then\(' | grep -v 'signal|cancelled|abort' | grep -v '.test.' 5. Add tests for the new hooks and verify no 'setState on unmounted component' warnings appear when rapidly navigating affected screens.

---

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.