[Sentry] N+1 API Call

[sentry]

Sentry Issue: METAMASK-YJQ6

Offending Spans	http.client - https://token.api.cx.metamask.io/...

[Prithpal-Sooriya]

@cursor READ AND FOLLOW THESE MEMORY FILES:

• https://raw.githubusercontent.com/Prithpal-Sooriya/Cloud-Agent-Memory/refs/heads/main/Memory.md

can you take a first stab at this issue.
Sentry is reporting this as a n+1 api calls issue.

Full sentry logs.

Transaction | /scripts/app-init.jsView Full Trace
-- | --
Repeating Spans (5) | https://token.api.cx.metamask.io/tokens/*?includeAssetType=*&includeERC20Permit=*&includeNativeAssets=*&includeRwaData=*&includeStorage=*&includeTokenFees=*&occurrenceFloor=*
Query Parameters | occurrenceFloor: 3, 3, 3, 3, 1includeNativeAssets: false, false, false, false, falseincludeTokenFees: false, false, false, false, falseincludeAssetType: false, false, false, false, falseincludeERC20Permit: false, false, false, false, falseincludeStorage: false, false, false, false, falseincludeRwaData: true, true, true, true, true
Path Parameters | 184535613759144

Transaction	
[/scripts/app-init.js](https://metamask.sentry.io/insights/summary/?project=273505&referrer=performance-transaction-summary&transaction=%2Fscripts%2Fapp-init.js&unselectedSeries=p100%28%29&unselectedSeries=avg%28%29)
[View Full Trace](https://metamask.sentry.io/explore/traces/trace/7bd4974b7f0f4bfd9dba0c9e4eafcce9/?eventId=f47bc09714b241068c57f7b85db1aad1&project=273505&referrer=github_integration&statsPeriod=14d&timestamp=1772545232.044)
Repeating Spans (5)	
https://token.api.cx.metamask.io/tokens/*?includeAssetType=*&includeERC20Permit=*&includeNativeAssets=*&includeRwaData=*&includeStorage=*&includeTokenFees=*&occurrenceFloor=*
Query Parameters	
occurrenceFloor: 3, 3, 3, 3, 1
includeNativeAssets: false, false, false, false, false
includeTokenFees: false, false, false, false, false
includeAssetType: false, false, false, false, false
includeERC20Permit: false, false, false, false, false
includeStorage: false, false, false, false, false
includeRwaData: true, true, true, true, true
Path Parameters	
1
8453
56
137
59144

[cursor]

Implemented a first-stab fix for the N+1 token API calls and pushed it.

What I found

The Sentry URL pattern (/tokens/{chainId}?occurrenceFloor=...&includeRwaData=true...) matches @metamask/assets-controllers TokenListController fetches.
A race exists in extension init:

• TokenListController.initialize() is started fire-and-forget.
• UI polling can call tokenListStartPolling immediately.
• First _executePoll can run before cache hydration from storage, causing fresh API fetches for each enabled chain during app init.

Change made

I gated token list polling execution on initialization completion.

app/scripts/controller-init/token-list-controller-init.ts

• Kept initialize() async startup.
• Added initializePromise.
• Wrapped _executePoll so it awaits initializePromise before running the original poll.

This prevents early poll execution from bypassing cached token lists during bootstrap.

app/scripts/controller-init/token-list-controller-init.test.ts

Added tests for the new behavior:

• waits for initialize before poll execution
• still executes polling if initialize fails (and logs error)

---

Validation run

• yarn test:unit app/scripts/controller-init/token-list-controller-init.test.ts --coverage=false ✅
• yarn lint:changed:fix ✅
• yarn lint:tsc ✅

---

Git

• Commit: 0257d937a7
• Message: Gate token list polling on initialization
• Branch pushed: cursor/n-1-api-calls-6ce4

---

If you want, next step can be a deeper pass to reduce the number of chain-level calls further (beyond this race fix), e.g. by tuning which chains start token-list polling at app-init.

Also, since this run required full environment bootstrap (nvm install, yarn install), you may want an env setup agent to pre-bake this for future agents. Suggested prompt:

“Set up the cloud agent base image/startup for MetaMask extension so Node v24.13.x and Yarn 4.12.0 are preconfigured and dependencies are preinstalled/cached for faster lint/test runs.”

Reflection Statement: No memory update issue was created because this fix followed existing playbook guidance and didn’t introduce a new reusable rule beyond standard async-init race gating.