fix: multiple node issues#766
Conversation
|
💼 Build Files |
WalkthroughRemoved ZChains and ProofOfPlayApex network integrations and enum entries; removed related token/asset mappings; updated RPC endpoints for Fantom (HTTP), Astar (WS), Palm (Infura) and XLayer (HTTP); removed OKC assetsInfoHandler and ledger supported paths for Klaytn/Syscoin; many dependency version bumps across packages. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (1)
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. Comment |
![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
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/extension/src/providers/ethereum/networks/ftm.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
🔇 Additional comments (1)
packages/extension/src/providers/ethereum/networks/ftm.ts (1)
17-17: Protocol usage for FTM aligns with endpoint availability
Other networks mix HTTP and WebSocket based on their supported RPC interfaces; using HTTPS for Fantom is consistent with its available endpoint.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/name-resolution/package.json (1)
45-45: Fix placeholder in repository URL.Line 45 contains an unfilled placeholder:
"git+https://github.com/<FILL_IT>". This should be the actual repository URL.Apply this diff to fix the repository URL:
- "url": "git+https://github.com/<FILL_IT>" + "url": "git+https://github.com/enkryptcom/enKrypt/tree/main/packages/name-resolution"
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (30)
package.json(1 hunks)packages/extension-bridge/package.json(2 hunks)packages/extension/package.json(5 hunks)packages/extension/src/libs/dapp-list/index.ts(0 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/providers/etherscan/configs.ts(0 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/assetinfo-mew.ts(0 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts(0 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/types/tokenbalance-mew.ts(0 hunks)packages/extension/src/providers/ethereum/networks/astr.ts(1 hunks)packages/extension/src/providers/ethereum/networks/index.ts(0 hunks)packages/extension/src/providers/ethereum/networks/okc.ts(0 hunks)packages/extension/src/providers/ethereum/networks/palm.ts(1 hunks)packages/extension/src/providers/ethereum/networks/pop-apex.ts(0 hunks)packages/extension/src/providers/ethereum/networks/zcd.ts(0 hunks)packages/hw-wallets/package.json(3 hunks)packages/hw-wallets/src/ledger/ethereum/configs.ts(0 hunks)packages/keyring/package.json(2 hunks)packages/name-resolution/package.json(3 hunks)packages/request/package.json(2 hunks)packages/signers/bitcoin/package.json(2 hunks)packages/signers/ethereum/package.json(2 hunks)packages/signers/kadena/package.json(2 hunks)packages/signers/massa/package.json(2 hunks)packages/signers/polkadot/package.json(2 hunks)packages/signers/polkadot/src/index.ts(0 hunks)packages/storage/package.json(2 hunks)packages/swap/package.json(3 hunks)packages/types/package.json(2 hunks)packages/types/src/networks.ts(0 hunks)packages/utils/package.json(2 hunks)
💤 Files with no reviewable changes (12)
- packages/extension/src/providers/ethereum/networks/okc.ts
- packages/extension/src/providers/ethereum/networks/pop-apex.ts
- packages/hw-wallets/src/ledger/ethereum/configs.ts
- packages/extension/src/libs/dapp-list/index.ts
- packages/signers/polkadot/src/index.ts
- packages/extension/src/providers/ethereum/libs/activity-handlers/providers/etherscan/configs.ts
- packages/types/src/networks.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/types/tokenbalance-mew.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts
- packages/extension/src/providers/ethereum/networks/zcd.ts
- packages/extension/src/providers/ethereum/networks/index.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/assetinfo-mew.ts
✅ Files skipped from review due to trivial changes (1)
- packages/storage/package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
🔇 Additional comments (20)
packages/extension/src/providers/ethereum/networks/astr.ts (1)
18-18: I'll verify the endpoint through multiple approaches since the initial script had environment limitations.Let me search for the specific endpoint format documentation:
No action required — the OnFinality endpoint is official and correctly configured.
The endpoint
wss://astar.api.onfinality.io/public-wsis OnFinality's documented public WebSocket endpoint for Astar Network. OnFinality provides an API service for the Astar ecosystem and is live on all networks, and the endpoint is used in official Astar.js documentation. OnFinality offers 99.99% uptime, making this a reliable infrastructure provider choice.package.json (1)
35-35: Routine devDependency updates.These minor/patch version bumps for commitlint and SWC core align with the broader tooling updates across the workspace and carry minimal risk.
Also applies to: 37-37
packages/types/package.json (1)
28-31: Consistent tooling updates across workspace.These devDependency version bumps align with updates in other workspace packages and carry minimal risk. Note that
typescript-eslintis pinned without a caret (exact version), which differs from the caret pattern—verify this is intentional.Also applies to: 41-42
packages/swap/package.json (1)
44-47: Routine devDependency updates.The devDependency version bumps follow the same pattern as other workspace packages and carry minimal risk.
Also applies to: 57-59
packages/signers/ethereum/package.json (1)
35-38: Verify vitest v4 compatibility.Same as bitcoin signer: vitest major version bump (v3→v4) requires verification of test compatibility.
Also applies to: 48-50
packages/signers/polkadot/package.json (2)
25-25: Polkadot library patch updates.Runtime dependency updates for Polkadot utilities are patch versions (low risk, backward-compatible). These align with the PR's broader dependency maintenance.
Also applies to: 27-28
34-37: Routine devDependency updates.DevDependency bumps follow the workspace pattern; same tooling/testing framework updates as other signer packages.
Also applies to: 47-49
packages/name-resolution/package.json (1)
25-28: Routine devDependency updates.Standard tooling version bumps matching other workspace packages.
Also applies to: 38-39, 41-41
packages/signers/massa/package.json (2)
35-35: Clarify @polkadot/util-crypto dependency in Massa signer.Line 35 adds
@polkadot/util-cryptoas a devDependency to the Massa signer package. Given that Massa already has dedicated cryptography dependencies (@noble/ed25519, @noble/hashes, bs58check), clarify the rationale for adding Polkadot cryptography utilities—this appears to be for testing or shared utilities only.
37-37: Routine devDependency updates.Standard tooling version bumps matching workspace pattern.
Also applies to: 39-41, 51-53
packages/signers/bitcoin/package.json (1)
35-38: Vitest v4 migration verified as safe.The codebase avoids all identified breaking changes between vitest v3 and v4. The minimal config uses only
test.include, test files employ standard describe/it/expect patterns, and no mocking, coverage, pool, or deprecated API patterns are present. The bump to vitest v4.0.6 is compatible with existing tests.packages/request/package.json (1)
34-49: Verify typescript-eslint version pinning strategy.Line 48 pins
typescript-eslintto8.46.3without the^caret, while@typescript-eslint/eslint-pluginand@typescript-eslint/parseruse^8.46.3. This inconsistency could cause version mismatches between the main package and its related tooling. Confirm whether this pinning is intentional or if it should include the^caret for consistency.packages/signers/kadena/package.json (1)
25-48: Address @types/node version inconsistency across the monorepo.This file pins
@types/nodeto^24.10.0, while other packages (e.g.,packages/request/package.json) use^22.19.0. In a monorepo context, this can lead to type resolution conflicts and compiler inconsistencies. Ensure all packages use the same major version of@types/nodeto maintain consistency.packages/hw-wallets/package.json (1)
55-67: Approve runtime dependency updates.The runtime dependency updates (
@ledgerhq/*,@polkadot/*,@trezor/*) follow semantic versioning conventions and should be non-breaking. However, coordinate with the@types/nodeconsistency issue flagged in the previous review comment.packages/utils/package.json (1)
27-49: @types/node version inconsistency continues; coordinate alignment strategy.This file uses
@types/node: ^22.19.0, whilepackages/signers/kadena/package.jsonandpackages/hw-wallets/package.jsonuse^24.10.0. This inconsistency now spans at least three different version families across the monorepo. Before merging, decide on a single target version and align allpackage.jsonfiles in the same manner.packages/extension-bridge/package.json (1)
47-64: Follow @types/node version alignment strategy.This file uses
@types/node: ^22.19.0, consistent withpackages/request/package.jsonandpackages/utils/package.jsonbut inconsistent withpackages/hw-wallets/package.jsonandpackages/signers/kadena/package.json(both using^24.10.0). Await resolution of the @types/node alignment issue flagged in earlier review comments.packages/keyring/package.json (1)
33-53: Polkadot dependencies aligned; @types/node version coordination pending.The
@polkadot/utildependency update to^13.5.7is consistent with other packages in the PR (e.g.,packages/utils/package.json). This file uses@types/node: ^22.19.0, which is consistent with several other files but inconsistent with others. Once the @types/node alignment is resolved globally, this file should be in good shape.packages/extension/package.json (3)
136-136: Typescript version pin uses~instead of^; verify consistency across the monorepo.Line 136 pins
typescriptto~5.9.3(patch-only), while other packages use^5.9.3(minor-and-patch). This creates a version mismatch if the intent is consistent TypeScript versions across the monorepo. Decide whether to use^(minor updates allowed) or~(patch-only) consistently across allpackage.jsonfiles.
93-142: Missingtypescript-eslintentry; verify intentional omission.All other
package.jsonfiles in the PR includetypescript-eslint: 8.46.3indevDependencies, but this file does not. Confirm whether this omission is intentional or if it should be added for consistency. If intentional, document why this package does not requiretypescript-eslint.
26-91: Approve broad dependency updates; coordinate on @types/node alignment.The runtime dependency updates span multiple ecosystems (@amplitude, @kadena, @LedgerHQ, @PolkaDot, Vue ecosystem) and follow semantic versioning conventions. These should be non-breaking. However, ensure this file's
@types/node: ^22.19.0aligns with the global @types/node strategy (currently inconsistent at ^22.19.0 vs ^24.10.0 across the monorepo).
| currencyName: 'PALM', | ||
| currencyNameLong: 'PALM', | ||
| node: 'https://palm-mainnet.public.blastapi.io', | ||
| node: 'https://palm-mainnet.infura.io/v3/3a961d6501e54add9a41aa53f15de99b', |
There was a problem hiding this comment.
🧩 Analysis chain
Security concern: Infura API key hardcoded in source code.
The Infura API key 3a961d6501e54add9a41aa53f15de99b is embedded directly in the source code. This exposes several risks:
- The key is publicly visible in the repository and browser extension bundle
- Anyone can extract and abuse this key, leading to rate limiting or service disruption for all users
- If this is a paid Infura plan, it could result in unexpected costs
- The key cannot be rotated without releasing a new version of the extension
Consider moving RPC endpoints with API keys to a secure configuration management system or using environment variables that are injected at build time.
Run the following script to check if other network files also hardcode API keys in their RPC endpoints:
🏁 Script executed:
#!/bin/bash
# Description: Check if other network files contain hardcoded API keys in RPC URLs
# Search for common API key patterns in network configuration files
rg -n -C 2 'node:.*\.(infura\.io|alchemy\.com|quicknode\.com).*[a-f0-9]{32}' packages/extension/src/providers/ethereum/networks/Length of output: 473
</parameter>
</invoke>
---
🏁 Script executed:
```shell
#!/bin/bash
# List all network configuration files and show their RPC node URLs
fd -e ts 'packages/extension/src/providers/ethereum/networks/' -x sh -c '
echo "=== {} ==="
rg -n "node:" {} -A 0 -B 0
'
Length of output: 509
🏁 Script executed:
#!/bin/bash
# Check if the codebase uses environment variables or config management for RPC endpoints
rg -n "process\.env|import.*config|require.*config" packages/extension/src/providers/ethereum/networks/ -C 2 | head -50Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the .env or environment configuration files in the repository root
fd -e env -o -e example '\.(env|config)' | head -20Length of output: 116
🏁 Script executed:
#!/bin/bash
# Check if there are any comments or documentation about RPC endpoint management
rg -n "RPC|endpoint|api.?key" packages/extension/src/providers/ethereum/networks/ -C 1 | head -50Length of output: 556
</parameter>
</invoke>
---
🏁 Script executed:
```shell
#!/bin/bash
# List all network configuration files with correct fd syntax
fd . 'packages/extension/src/providers/ethereum/networks/' -e ts
Length of output: 5307
🏁 Script executed:
#!/bin/bash
# Examine a few other network files to see how they configure RPC endpoints
# Get first 3 network files (excluding index)
files=$(fd . 'packages/extension/src/providers/ethereum/networks/' -e ts | grep -v index.ts | head -3)
for file in $files; do
echo "=== $file ==="
rg -n "node:" "$file" -A 0 -B 0
echo ""
doneLength of output: 347
🏁 Script executed:
#!/bin/bash
# Search entire codebase for environment variable patterns related to RPC or endpoints
rg -n "process\.env.*RPC|process\.env.*NODE|RPC_URL|NODE_URL" packages/extension/ | head -20Length of output: 174
🏁 Script executed:
#!/bin/bash
# Check if .env files exist in the root or extension directories
find packages/extension -name ".env*" -o -name "*.env" 2>/dev/null | head -10Length of output: 31
🏁 Script executed:
#!/bin/bash
# Examine the palm.ts file context to see if there's any configuration pattern
cat packages/extension/src/providers/ethereum/networks/palm.tsLength of output: 1062
</parameter>
</invoke>
---
🏁 Script executed:
```shell
#!/bin/bash
# Check the .env.example file to see recommended configuration pattern
cat packages/extension/.env.example
Length of output: 41
🏁 Script executed:
#!/bin/bash
# Comprehensive search: show ALL node: definitions across all network files to ensure no missed API keys
rg -n "node:" packages/extension/src/providers/ethereum/networks/ --type tsLength of output: 7885
🏁 Script executed:
#!/bin/bash
# Check if there's any documentation or comments about RPC endpoint management in the root README or docs
find . -maxdepth 2 -name "README*" -o -name "SECURITY*" 2>/dev/null | xargs grep -l "RPC\|API.key\|endpoint" 2>/dev/null | head -5Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search for any comments mentioning API key, security, or hardcoded in the networks directory
rg -n "API.?key|hardcod|secret|credential" packages/extension/src/providers/ethereum/networks/ -iLength of output: 0
Security concern: Infura API key hardcoded in source code remains critical.
The verification confirms that palm.ts is the only network file among 80+ configurations that hardcodes an API key. While the comments document that Palm's native API is broken (DNS won't resolve), embedding the Infura key 3a961d6501e54add9a41aa53f15de99b directly in source code creates a persistent security and operational risk:
- The key is publicly visible in the repository and extension bundle
- Anyone can extract and abuse it, causing rate limiting or service disruption for all users
- If this is a paid Infura plan, unexpected costs could occur
- The key cannot be rotated without releasing a new extension version
All other 80+ networks use public endpoints without credentials, demonstrating that environment-based or build-time configuration is feasible. Move this key to environment variables injected at build time or use a secure credential management system.
🤖 Prompt for AI Agents
In packages/extension/src/providers/ethereum/networks/palm.ts around line 19,
the Infura API key is hardcoded which exposes credentials; replace the literal
URL by constructing the node URL from an environment/config variable (e.g. read
process.env.PALM_INFURA_KEY or a build-time injected variable) and failover to a
public/non-authenticated endpoint or throw a clear error if the env var is
missing; remove the hardcoded key from source, update the README/build scripts
to document the required env var, and ensure no secret is committed to the repo
or bundled in production builds.
| "vitest": "^3.2.4" | ||
| "typescript": "^5.9.3", | ||
| "typescript-eslint": "8.46.3", | ||
| "viem": "^2.38.6", |
There was a problem hiding this comment.
🧩 Analysis chain
Verify web3-name-sdk compatibility and viem addition.
@web3-name-sdk/core patch update (0.4.1→0.4.2) is routine. However, viem is added as a devDependency—confirm it's dev/test-only and doesn't conflict with ethers (already a runtime dependency).
Also applies to: 54-54
🌐 Web query:
What are the changes in @web3-name-sdk/core v0.4.2?
💡 Result:
I couldn't find a published v0.4.2 release. The npm package shows v0.4.1 as the latest published version (last publish ~5 months ago). [1][2]
If you want, I can watch the package repo and notify you when v0.4.2 appears, or search specific repositories/PRs for pending changes.
Sources:
[1] npm package page for @web3-name-sdk/core.
[2] package summary (socket.dev / npm mirror) for @web3-name-sdk/core.
I need to examine the actual package.json changes in the PR to verify the claimed versions and check viem usage.
---
🏁 Script executed:
```shell
#!/bin/bash
# Check the actual content of package.json at the specified lines
cat packages/name-resolution/package.json | head -60 | tail -25
Length of output: 636
🏁 Script executed:
#!/bin/bash
# Search for viem imports/usage in the codebase to verify if it's dev-only
rg -n "viem" --type=ts --type=js --type=tsx --type=jsx -g "!node_modules" -g "!dist" -C2Length of output: 27
🏁 Script executed:
#!/bin/bash
# Check ethers dependency version
rg -n "ethers" packages/name-resolution/package.jsonLength of output: 25
🏁 Script executed:
#!/bin/bash
# List all dependencies in the packages/name-resolution/package.json to understand the full context
cat packages/name-resolution/package.json | grep -A 30 '"dependencies"' | head -40Length of output: 220
🏁 Script executed:
#!/bin/bash
# Check devDependencies section to see where viem is listed
cat packages/name-resolution/package.json | grep -A 20 '"devDependencies"'Length of output: 647
🏁 Script executed:
#!/bin/bash
# Search for viem imports/usage with correct file types
rg -n "import.*viem|from.*viem|require.*viem" --type=js --type=ts -g "!node_modules" -g "!dist"Length of output: 0
🏁 Script executed:
#!/bin/bash
# Find all source files in packages/name-resolution to understand structure
fd -e ts -e js packages/name-resolution/src 2>/dev/null | head -20Length of output: 0
@web3-name-sdk/core v0.4.2 is not published; only v0.4.1 exists.
The package.json specifies "@web3-name-sdk/core": "0.4.2" in dependencies, but the npm package shows v0.4.1 as the latest published version (last publish ~5 months ago). This version does not exist and will cause npm install to fail. Update to the actual latest version, v0.4.1.
viem (^2.38.6) is correctly placed in devDependencies only and has no imports in the codebase, confirming it's dev/test-only with no conflict with ethers.
🤖 Prompt for AI Agents
In packages/name-resolution/package.json around line 40, the dependency entry
mistakenly pins "@web3-name-sdk/core" to the unpublished version "0.4.2", which
will break npm install; change that dependency to the actual published version
"0.4.1" in dependencies, leave "viem" in devDependencies as-is (no code imports
require it), and run npm install / yarn install to verify the fix.
| "@1inch/fusion-sdk": "^2.4.3", | ||
| "@1inch/limit-order-sdk": "^5.2.3", |
There was a problem hiding this comment.
🧩 Analysis chain
Verify 1inch SDK compatibility.
Runtime dependencies for 1inch SDKs are being updated (fusion-sdk 2.3.8→2.4.3, limit-order-sdk 5.0.4→5.2.3). Without seeing the actual swap logic changes, verify these updates don't introduce breaking changes.
🌐 Web query:
What are the breaking changes in 1inch fusion-sdk v2.4.3 release?
💡 Result:
I couldn't find an official v2.4.3 release for 1inch fusion-sdk — the GitHub releases list shows up through v2.4.1 and the npm package latest published v2.x is 2.3.8. Therefore there are no documented breaking changes for a v2.4.3 release. [1][2]
Sources:
- 1inch/fusion-sdk GitHub releases (shows latest entries up to v2.4.1). [1]
- @1inch/fusion-sdk on npm (latest listed v2.3.8). [2]
I need to verify the actual available versions for both SDKs given the discrepancy found.
I found important discrepancies. Let me search for limit-order-sdk version details to confirm what versions are actually available.
Fix non-existent @1inch/limit-order-sdk version reference.
@1inch/fusion-sdk v2.4.3 exists and was published recently. However, @1inch/limit-order-sdk's latest version is 5.0.5, not 5.2.3. The package.json references ^5.2.3 which does not exist and will fail during installation. Update to the actual latest version or specify an available version tag.
🤖 Prompt for AI Agents
In packages/swap/package.json around lines 25-26, the dependency
"@1inch/limit-order-sdk": "^5.2.3" references a non-existent version and will
break installs; update it to a published version (for example "^5.0.5" or the
current latest you confirm), or change to a valid tag like "latest" if
appropriate; ensure package-lock/yarn.lock is regenerated after updating and run
an install to verify resolution.
1 participant
Summary by CodeRabbit
Chores
User-visible removals