feat: regenerate asset data 08/21/2025#10332
Conversation
📝 WalkthroughWalkthroughUpdates asset data files: adds/removes ERC20 color mappings in color-map.json; fully regenerates encoded related-asset index; and appends a new clearAssets migration (166) to the state migration manifest. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor App as App Startup
participant MR as MigrationRunner
participant Store as State Store
participant AS as AssetService
App->>MR: Run pending migrations
MR->>Store: Apply 0..165
MR->>Store: Apply 166: clearAssets
Note right of MR: New step added in this PR
MR-->>App: Migrations complete
App->>AS: Load asset data
AS-->>App: color-map + encodedRelatedAssetIndex loaded
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/state/migrations/index.ts (1)
42-210: Optional: generate this monotonous mapping to avoid manual increments.If desired, replace the literal 0..166 object with a small helper to eliminate off-by-one risks during daily bumps.
Proposed diff within this file:
-export const clearAssetsMigrations = { - 0: clearAssets, - 1: clearAssets, - 2: clearAssets, - ... - 165: clearAssets, - 166: clearAssets, -} as unknown as Omit<MigrationManifest, '_persist'> +export const clearAssetsMigrations = Object.fromEntries( + Array.from({ length: 166 + 1 }, (_, i) => [i, clearAssets]) +) as unknown as Omit<MigrationManifest, '_persist'>If you prefer stronger typing, add this helper above the exports:
const makeClearMigrations = (last: number) => Object.fromEntries(Array.from({ length: last + 1 }, (_, i) => [i, clearAssets])) as unknown as Omit<MigrationManifest, '_persist'> // usage: // export const clearAssetsMigrations = makeClearMigrations(166)scripts/generateAssetData/color-map.json (1)
184-14075: Adjust validation to exempt manually maintained native assetsThe current script fails because it treats all
/slip44:entries as errors, but per team conventions native assets (CAIP-19 slip44 entries) are manually hardcoded and should not be validated by the CI‐generated asset checks. Update the validation script to:
- Skip any
/slip44:keys (manual native assets) instead of erroring- Only run key‐format, address, color, and
/bep20checks against ERC20/BEP20 entriesLocations to update:
scripts/generateAssetData/color-map.jsonvalidation block in your review commentSuggested diff for the review comment’s script:
# 2) Ensure no native slip44 entries are present in this generated map -if rg -n "/slip44:" "$file" >/dev/null; then - echo "ERROR: Found slip44 native assets in color-map.json (should be excluded from generated data)." - rg -n "/slip44:" "$file" - exit 1 -fi +# Step 2 is skipped: native assets (slip44) are manually maintained and exempt from CI validation # 3) Validate keys follow eip155:<chainId>/(erc20|bep20):0x<40 lowercase hex>With this change, the script will only enforce format and conventions on generated tokens and leave native slip44 entries untouched.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (7)
packages/caip/src/adapters/coincap/generated/eip155_1/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_1/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_137/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_43114/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_56/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_8453/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/solana_5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/adapter.jsonis excluded by!**/generated/**
📒 Files selected for processing (3)
scripts/generateAssetData/color-map.json(30 hunks)src/lib/asset-service/service/encodedRelatedAssetIndex.json(1 hunks)src/state/migrations/index.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/*.{ts,tsx}: ALWAYS use Result<T, E> pattern for error handling in swappers and APIs
ALWAYS use Ok() and Err() from @sniptt/monads for monadic error handling
ALWAYS use custom error classes from @shapeshiftoss/errors
ALWAYS provide meaningful error codes for internationalization
ALWAYS include relevant details in error objects
ALWAYS wrap async operations in try-catch blocks
ALWAYS use AsyncResultOf utility for converting promises to Results
ALWAYS provide fallback error handling
ALWAYS use timeoutMonadic for API calls
ALWAYS provide appropriate timeout values for API calls
ALWAYS handle timeout errors gracefully
ALWAYS validate inputs before processing
ALWAYS provide clear validation error messages
ALWAYS use early returns for validation failures
ALWAYS log errors for debugging
ALWAYS use structured logging for errors
ALWAYS include relevant context in error logs
Throwing errors instead of using monadic patterns is an anti-pattern
Missing try-catch blocks for async operations is an anti-pattern
Generic error messages without context are an anti-pattern
Not handling specific error types is an anti-pattern
Missing timeout handling is an anti-pattern
No input validation is an anti-pattern
Poor error logging is an anti-pattern
Using any for error types is an anti-pattern
Missing error codes for internationalization is an anti-pattern
No fallback error handling is an anti-pattern
Console.error without structured logging is an anti-pattern
**/*.{ts,tsx}: ALWAYS use camelCase for variables, functions, and methods
ALWAYS use descriptive names that explain the purpose for variables and functions
ALWAYS use verb prefixes for functions that perform actions
ALWAYS use PascalCase for types, interfaces, and enums
ALWAYS use descriptive names that indicate the structure for types, interfaces, and enums
ALWAYS use suffixes like Props, State, Config, Type when appropriate for types and interfaces
ALWAYS use UPPER_SNAKE_CASE for constants and configuration values
ALWAYS use d...
Files:
src/state/migrations/index.ts
**/*
📄 CodeRabbit inference engine (.cursor/rules/naming-conventions.mdc)
**/*: ALWAYS use appropriate file extensions
Flag files without kebab-case
Files:
src/state/migrations/index.tssrc/lib/asset-service/service/encodedRelatedAssetIndex.jsonscripts/generateAssetData/color-map.json
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)
USE Redux only for global state shared across multiple places
Files:
src/state/migrations/index.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: NeOMakinG
PR: shapeshift/web#10136
File: src/lib/asset-service/service/encodedRelatedAssetIndex.json:1-1
Timestamp: 2025-07-29T10:22:27.037Z
Learning: PRs with titles starting with "feat: regenerate asset data" are routine daily asset updates that don't need detailed code analysis. Users prefer to skip automated reviews for these maintenance PRs using coderabbitai ignore.
Learnt from: 0xApotheosis
PR: shapeshift/web#10290
File: scripts/generateAssetData/color-map.json:41-47
Timestamp: 2025-08-17T21:53:03.806Z
Learning: In the ShapeShift web codebase, native assets (using CAIP-19 slip44 namespace like eip155:1/slip44:60, bip122:.../slip44:..., cosmos:.../slip44:...) are manually hardcoded and not generated via the automated asset generation script. Only ERC20/BEP20 tokens go through the asset generation process. The validation scripts should only validate generated assets, not manually added native assets.
📚 Learning: 2025-08-17T21:53:03.806Z
Learnt from: 0xApotheosis
PR: shapeshift/web#10290
File: scripts/generateAssetData/color-map.json:41-47
Timestamp: 2025-08-17T21:53:03.806Z
Learning: In the ShapeShift web codebase, native assets (using CAIP-19 slip44 namespace like eip155:1/slip44:60, bip122:.../slip44:..., cosmos:.../slip44:...) are manually hardcoded and not generated via the automated asset generation script. Only ERC20/BEP20 tokens go through the asset generation process. The validation scripts should only validate generated assets, not manually added native assets.
Applied to files:
scripts/generateAssetData/color-map.json
🧬 Code graph analysis (1)
src/state/migrations/index.ts (1)
src/state/migrations/clearAssets.ts (1)
clearAssets(6-8)
🔇 Additional comments (33)
src/state/migrations/index.ts (1)
209-210: LGTM: Migration 166 correctly added – contiguity and version sync validated.
- clearAssetsMigrations contains keys 0 through 166 (167 entries) with no gaps or duplicates.
- assetsPersistConfig.version computes
Math.max(...Object.keys(clearAssetsMigrations).map(Number)), resolving to 166.This aligns with our routine daily “feat: regenerate asset data” PRs.
If you’d like me to auto-skip future regen PRs viacoderabbitai ignore, just let me know.scripts/generateAssetData/color-map.json (32)
187-187: Routine ERC20 color addition – LGTM.
Key format and hex color look consistent with existing entries.
426-426: Routine ERC20 color addition – LGTM.
Consistent CAIP-19 key and 6-digit uppercase hex color.
993-993: Routine ERC20 color addition – LGTM.
Lowercased address and color format align with file conventions.
1446-1446: Routine ERC20 color addition – LGTM.
No issues spotted with key or color formatting.
1459-1459: Routine ERC20 color addition – LGTM.
CAIP-19 path and color are valid.
2772-2772: Routine ERC20 color addition – LGTM.
Formatting consistent; nothing actionable.
3231-3231: Routine ERC20 color addition – LGTM.
Address casing and color code conform to conventions.
3341-3341: Routine ERC20 color addition – LGTM.
No anomalies detected.
3910-3910: Routine ERC20 color addition – LGTM.
Key namespace and color are well-formed.
4397-4397: Routine ERC20 color addition – LGTM.
Matches established formatting; approve.
4436-4436: Routine ERC20 color addition – LGTM.
Consistent with surrounding entries.
4732-4732: Routine ERC20 color addition – LGTM.
Color hex and key look correct.
5712-5712: Routine ERC20 color addition – LGTM.
Formatting and style consistent.
5716-5716: Note: Same token color reused across chains – confirm intent.
This address also appears on other networks in this PR mapped to the same color (#764CEF). If that’s intentional for brand consistency, all good.
7301-7301: Routine Polygon ERC20 color addition – LGTM.
CAIP-19 path and color are valid.
7545-7545: Routine Arbitrum ERC20 color addition – LGTM.
Nothing concerning; consistent formatting.
7750-7750: Routine Arbitrum ERC20 color addition – LGTM.
Address/color formatting matches conventions.
8970-8970: Note: Cross-chain same address/color – verify consistency is desired.
Same address/color appears on L1 and AVAX. Assuming CREATE2/same-address deploys, this is fine; just confirming it’s intentional.
9410-9410: Routine BSC BEP20 color addition – LGTM.
Key uses /bep20 under eip155:56 as expected.
9515-9515: Routine BSC BEP20 color addition – LGTM.
No issues spotted.
10254-10254: Routine BSC BEP20 color addition – LGTM.
Formatting and casing consistent.
10345-10345: Routine BSC BEP20 color addition – LGTM.
CAIP-19 key and color are valid.
11060-11060: Routine BSC BEP20 color addition – LGTM.
No anomalies detected.
11491-11491: Routine BSC BEP20 color addition – LGTM.
Consistent with surrounding entries.
12539-12539: Routine Base ERC20 color addition – LGTM.
Key and color formatting look correct.
12813-12813: Routine Base ERC20 color addition – LGTM.
Address casing and color are correct.
13330-13330: Routine Base ERC20 color addition – LGTM.
Nothing actionable here.
13366-13366: Routine Base ERC20 color addition – LGTM.
Formatting checks out.
13664-13664: Routine Base ERC20 color addition – LGTM.
CAIP-19 path and color are valid.
13994-13994: Routine Base ERC20 color addition – LGTM.
Address/color formatting consistent.
14002-14002: Routine Base ERC20 color addition – LGTM.
No issues spotted.
14072-14072: Routine Base ERC20 color addition – LGTM.
Same address/color appears on Polygon (Line 7301) as well; assuming intentional brand consistency across chains.
3 participants
Generated from CI.
Summary by CodeRabbit