Conversation
WalkthroughAdds support for a new testnet network (arctestnet) across configuration, deployment manifests, and deployment scripts. Includes network RPC endpoints, contract addresses, periphery configurations, deployment state, and async casting support in deployment utilities. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
script/deploy/_targetState.json (1)
2225-2251: Alphabetical ordering inconsistency.Per coding guidelines, network entries should be ordered with mainnet first, then all other networks alphabetically. The
arctestnetentry is placed at the end (afterjovay), but it should come afterarbitrum(around line 95-147).Additionally, note that
DexManagerFacetandWhitelistManagerFacetare not included in this configuration, unlike most other production network entries. If this is intentional for the testnet, no action needed; otherwise, consider adding them for consistency.📝 Suggested fix for ordering
Move the
arctestnetblock to appear afterarbitrumand beforeavalancheto maintain alphabetical ordering.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@script/deploy/_targetState.json` around lines 2225 - 2251, Move the "arctestnet" network block so it appears immediately after "arbitrum" (i.e., maintain mainnet first then other networks alphabetically) and ensure its production LiFiDiamond entry matches the typical facet set; if you want consistency add the missing "DexManagerFacet" and "WhitelistManagerFacet" keys to the "LiFiDiamond" object (or explicitly confirm they are intentionally omitted) so the configuration for "arctestnet" aligns with other production network entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@script/tasks/updateERC20Proxy.sh`:
- Line 30: The call to universalCast in updateERC20Proxy.sh hardcodes the
environment as "production" which ignores the ENVIRONMENT variable and can route
privileged transactions incorrectly; update the universalCast invocation (the
line using universalCast "send" "$NETWORK" "production" "$ERC20PROXY"
"setAuthorizedCaller(address,bool)" "$EXECUTOR true" "false") to use the
ENVIRONMENT variable (e.g. "$ENVIRONMENT") instead of the literal "production"
so the script respects the passed environment for staging/testnet runs.
---
Nitpick comments:
In `@script/deploy/_targetState.json`:
- Around line 2225-2251: Move the "arctestnet" network block so it appears
immediately after "arbitrum" (i.e., maintain mainnet first then other networks
alphabetically) and ensure its production LiFiDiamond entry matches the typical
facet set; if you want consistency add the missing "DexManagerFacet" and
"WhitelistManagerFacet" keys to the "LiFiDiamond" object (or explicitly confirm
they are intentionally omitted) so the configuration for "arctestnet" aligns
with other production network entries.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 81642ef3-fb55-465b-8880-8b1a65cff618
📒 Files selected for processing (12)
config/networks.jsonconfig/permit2Proxy.jsonconfig/whitelist.jsondeployments/arctestnet.jsonfoundry.tomlscript/common/types.tsscript/deploy/_targetState.jsonscript/deploy/deployAllContracts.shscript/deploy/facets/UpdateDiamondLoupeFacet.s.solscript/helperFunctions.shscript/tasks/updateERC20Proxy.shscript/universalCast.sh
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
script/deploy/deployAllContracts.sh (1)
187-198:⚠️ Potential issue | 🟡 MinorMissing error check for DiamondLoupeFacet update.
The first
diamondUpdateFacetcall forUpdateDiamondLoupeFacet(line 192) lacks error checking. If this step fails, the script proceeds to update core facets anyway, potentially leaving the diamond in an inconsistent state.Consider adding a
checkFailurecall after line 192:Proposed fix
echo "[info] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> now adding DiamondLoupeFacet to diamond contract" diamondUpdateFacet "$NETWORK" "$ENVIRONMENT" "$DIAMOND_CONTRACT_NAME" "UpdateDiamondLoupeFacet" false + checkFailure $? "update DiamondLoupeFacet in $DIAMOND_CONTRACT_NAME on network $NETWORK" # update diamond with core facets🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@script/deploy/deployAllContracts.sh` around lines 187 - 198, The script calls diamondUpdateFacet "$NETWORK" "$ENVIRONMENT" "$DIAMOND_CONTRACT_NAME" "UpdateDiamondLoupeFacet" without checking for failure, so if that step fails the script continues and may leave the diamond inconsistent; after the diamondUpdateFacet call for "UpdateDiamondLoupeFacet" add a call to checkFailure (or the existing failure handler used elsewhere) to abort or handle errors before proceeding to the next diamondUpdateFacet for "UpdateCoreFacets", ensuring the check references the same DIAMOND_CONTRACT_NAME/NETWORK/ENVIRONMENT context.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@script/deploy/deployAllContracts.sh`:
- Around line 187-198: The script calls diamondUpdateFacet "$NETWORK"
"$ENVIRONMENT" "$DIAMOND_CONTRACT_NAME" "UpdateDiamondLoupeFacet" without
checking for failure, so if that step fails the script continues and may leave
the diamond inconsistent; after the diamondUpdateFacet call for
"UpdateDiamondLoupeFacet" add a call to checkFailure (or the existing failure
handler used elsewhere) to abort or handle errors before proceeding to the next
diamondUpdateFacet for "UpdateCoreFacets", ensuring the check references the
same DIAMOND_CONTRACT_NAME/NETWORK/ENVIRONMENT context.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 1c99b6fd-0bc3-403b-9b56-f57b571d166a
📒 Files selected for processing (10)
config/networks.jsonconfig/permit2Proxy.jsonconfig/whitelist.jsondeployments/arctestnet.diamond.jsondeployments/arctestnet.jsonfoundry.tomlscript/deploy/_targetState.jsonscript/deploy/deployAllContracts.shscript/helperFunctions.shscript/tasks/diamondUpdatePeriphery.sh
✅ Files skipped from review due to trivial changes (1)
- script/tasks/diamondUpdatePeriphery.sh
🚧 Files skipped from review as they are similar to previous changes (4)
- config/permit2Proxy.json
- foundry.toml
- config/networks.json
- script/helperFunctions.sh
Which Jira task belongs to this PR?
https://lifi.atlassian.net/browse/EX-308
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)