chore: reduce state writes from O(2n) to O(2) for NFT detection

[juanmigdr]

Explanation

Previously, addNfts called #addNftContract and #addIndividualNft in a loop, acquiring the mutex and writing to state once per NFT. For large detection batches this produced O(2n) state updates, triggering unnecessary downstream re-renders on every iteration.

This PR replaces the per-item private methods (#addNftContract, #addIndividualNft) with batched equivalents (#addNftContracts, #addMultipleNfts) that:

• Process all NFTs/contracts in a single mutex acquisition.
• Accumulate per-chain changes in memory, then call #updateNestedNftState once per modified chain rather than once per NFT.
• Wrap each item in an inner try/catch so a single failing NFT does not abort the entire batch.

As a side effect, addNft (singular) is updated to delegate to the same batched methods with a single-element array, keeping the two code paths consistent.

References

https://consensyssoftware.atlassian.net/browse/ASSETS-2819

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Refactors NFT add/detection flows to batch mutex acquisition and per-chain state updates, which could subtly change ordering/callback timing and error handling for NFT/contract additions. Also adjusts contract metadata fetching logic to conditionally skip RPC calls based on API-provided fields.

Overview
Batches NFT detection/addition state updates by replacing per-NFT #addNftContract/#addIndividualNft calls with #addNftContracts and #addMultipleNfts, reducing repeated mutex acquisitions and state writes to once per modified chainId.

Updates addNfts to accumulate contracts/NFTs in memory and write back in grouped updates, and updates addNft to delegate to the same batched path (surfacing the first collected error when present). #getNftContractInformation is also tightened to merge API metadata with on-chain name/symbol and skip RPC calls when the API already provided those fields.

^{Written by Cursor Bugbot for commit 700a43e. This will update automatically on new commits. Configure here.}

[juanmigdr]

@cursor update the assets-controllers changelog

[cursor]

I've successfully updated the assets-controllers changelog! Here's what I accomplished:

Changelog Update:

• Added an entry in the "Changed" section under "Unreleased" describing the NFT Controller optimization
• The entry documents how the PR reduces state writes from O(n) to O(1) for NFT detection through batching
• Properly formatted with PR reference chore: reduce state writes from O(2n) to O(2) for NFT detection #8079 following the project's changelog guidelines

Validation:

• Enabled corepack and installed dependencies to prepare the environment
• Ran yarn changelog:validate to ensure the format meets project standards
• All changelog validation checks passed successfully

Git Operations:

• Staged the updated changelog file
• Committed with descriptive message: "chore: update assets-controllers changelog for NFT detection optimization"
• Pushed changes to the remote branch

The changelog now properly documents this performance optimization, which should resolve the failing CI check for changelog validation.

  

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Mutex held during N sequential async network calls

Medium Severity

#addNftContracts acquires the mutex at the start and holds it across ALL iterations of the loop, including the await this.#getNftContractInformation() calls that make blockchain RPC requests. For a detection batch of up to 50 NFTs (per the API's limit=50) with many unique contracts, this means N sequential network calls (~100-500ms each) all execute under a single continuous mutex hold. The old per-item #addNftContract released the mutex between each contract, allowing other mutex-dependent operations like removeNft, updateNftMetadata, or user-initiated addNft to interleave. The network calls don't need mutex protection — only the state reads/writes do.

 

[sahar-fehri]

Hey @juanmigdr , is this comment valid?