fix(wallets): saving chain addresses no longer deletes engine tokens

[feruzm]

Fixes #1406.

Problem

profile.tokens is written wholesale, so whatever the payload contains becomes the user's entire on-chain token list. The two external-wallet screens send CHAIN entries only:

• setup-external-metamask.tsx:166 (link MetaMask)
• setup-external-import.tsx:96 (import watch-only address)

and getGroupedChainTokens filtered the carry-forward base to chain entries as well, so the broadcast replaced the list with chain addresses alone — silently deleting every Hive-Engine token the user had selected.

Reproduced against the real code before the fix:

BEFORE : LEO, POB, WAIV, BTC
AFTER  : BTC, ETH

profile.name survived, so the profile deep-merge was working correctly — it was the tokens array specifically being replaced.

Nothing outside Ecency writes profile.tokens, so the loss is unrecoverable: the user must re-pick every token, if they notice. The reach is unlucky too — profile-wallet-external-banner.tsx promotes the "link MetaMask" CTA specifically to accounts with no chain tokens yet, which is the population most likely to have a curated engine list.

Worth noting this produced the same user-visible symptom as the metadata-stripping node bug (#1393), by a completely different mechanism, and needs no misbehaving node.

Change

Entries the caller does not manage are now carried forward. Which those are is inferred from the payload:

• carries non-chain entries → the wallet token picker, which owns the complete list (it always sends the basic Hive assets plus every selected engine token, and deselecting one means omitting it). Nothing is preserved, so deselect still works.
• chain-only → an external-wallet screen, which knows nothing about engine tokens. The rest is preserved.

The degenerate case is safe: a picker submitting before its token list has loaded sends chain-only and therefore preserves, which is the non-destructive outcome.

Inferring rather than adding an option is deliberate — the apps resolve this package through the committed dist, so a new public option could not be used by a call site until the next release, whereas this fixes both screens with no app-side change.

The assembly moved into an exported buildTokensPayload so it is unit-testable without rendering the hook.

Verification

• packages/wallets suite: 146 passed (5 new).
• Both new tests confirmed non-vacuous: the preservation test fails without the carry-forward, and the deselect test fails if the carry-forward is applied unconditionally.
• tsc --noEmit clean for packages/wallets and apps/web.

Note for release

This is package-internal, and the apps consume @ecency/wallets through its committed dist. The fix does not reach ecency.com until the dist is rebuilt, which the release flow owns — I have not added any label or dist rebuild to this PR.

Audit context

From a full sweep of both repos (46 write-adjacent sites across apps/web, packages/*, apps/self-hosted and vision-mobile), these two call sites were the only unprotected posting_json_metadata writes; everything else routes through useAccountUpdate and is correctly protected. Separately, apps/web/src/api/operations.ts:846-863 serializes JSON.stringify({ profile }) and would drop non-profile root keys, but nothing imports api/operations — dead code, worth deleting in its own change.

[coderabbitai]

Warning

Review limit reached

@feruzm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 20 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e5ae1590-1654-471e-918e-c2dc0a426261

📥 Commits

Reviewing files that changed from the base of the PR and between 053f58b and 89ea5e4.

⛔ Files ignored due to path filters (7)

• packages/wallets/dist/browser/index.d.ts is excluded by !**/dist/**
• packages/wallets/dist/browser/index.js is excluded by !**/dist/**
• packages/wallets/dist/browser/index.js.map is excluded by !**/dist/**, !**/*.map
• packages/wallets/dist/node/index.cjs is excluded by !**/dist/**
• packages/wallets/dist/node/index.cjs.map is excluded by !**/dist/**, !**/*.map
• packages/wallets/dist/node/index.mjs is excluded by !**/dist/**
• packages/wallets/dist/node/index.mjs.map is excluded by !**/dist/**, !**/*.map

📒 Files selected for processing (3)

• packages/wallets/CHANGELOG.md
• packages/wallets/src/modules/wallets/mutations/save-wallet-information-to-metadata.spec.ts
• packages/wallets/src/modules/wallets/mutations/save-wallet-information-to-metadata.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}