refactor(tron-wallet-snap): assert supported networks at handler boundaries instead of casting - #402
Closed
ulissesferreira wants to merge 7 commits into
Closed
ulissesferreira wants to merge 7 commits into
ulissesferreira wants to merge 7 commits into
Conversation
…daries instead of casting
- Assert supported networks where data enters the snap: manifest scopes, AssetsController assets, Token API filtering and TrackTransaction background event params. - Carry the validated `Network` type instead of re-casting: sign renderers take `TronWalletKeyringRequest`, send uses `asset.network`, staking and zero-balance assets use `getAssetNetwork`. - Add `TronKeyringAccount` with `scopes: Network[]` for stored accounts; it remains assignable to the emitted `KeyringAccount`. - Build CAIP asset types from `Network` instead of `TrxScope`. - Add a lint rule banning casts to `Network` or `TrxScope` in the Tron snap.
Per review, keep the root ESLint config untouched: the no-tron-network-casts rule block and the shared no-enums selector extraction are dropped.
…ues(Network) The config structs validate the clients' baseUrls as record(NetworkStruct, UrlStruct), so keys are guaranteed to be supported networks. Iterating Object.values(Network) keeps that typing end to end, removing the Object.entries key-widening that previously forced a runtime isSupportedNetwork guard (and, before this PR, an 'as Network' cast).
This was referenced Oct 1, 2026
Closed
Contributor
Author
|
Superseded by #403 — rebased on latest main with the scope reduced to the type-consistency changes only. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
The Tron Snap handled scopes and networks coming from untrusted boundaries (RPC request params, the Keyring API) with forced casts (
chainId as Network,scope as Network), silently accepting values the Snap does not control and indexingNetworks[...]with them.This PR replaces those casts with runtime assertions at the handler boundary, matching how other request fields are validated:
isNetwork(type guard) andassertNetwork(throwsInvalidParamsError) next toNetworkinconstants.ClientRequestHandler: the fourchainId as Networkcasts (onAmountInput,confirmSend,claimUnstakedTrx,claimTrxStakingRewards) now useassertNetwork(chainId).KeyringHandler.resolveAccountAddress: the extension-providedscopeis asserted instead of cast.Follow-up work (out of scope): collapse the remaining internally-consistent casts (
SendService,StakingService, asset mappers) and the config/manifest-derived casts by flowingNetworkdown from these boundaries.Ticket: WPN-2217
References
Based on the review thread in #388. This PR is intended to serve as the base that #388 builds on. Supersedes #394 (branch rename).
Checklist