-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase robustness of confirm safe tx script #858
Conversation
WalkthroughThe pull request introduces a new key, Changes
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Test Coverage ReportLine Coverage: 76.20% (1685 / 2211 lines) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
script/utils/viemScriptHelpers.ts (1)
28-32
: Consider enhancing the colors implementationWhile the color constant is a good addition for consistent terminal output, consider these improvements:
-const colors = { - reset: '\x1b[0m', - red: '\x1b[31m', - green: '\x1b[32m', -} +// ANSI escape sequences for terminal colors +const supportsColor = process.stdout.hasColors?.(); +const colors = { + reset: supportsColor ? '\x1b[0m' : '', + red: supportsColor ? '\x1b[31m' : '', + green: supportsColor ? '\x1b[32m' : '', + yellow: supportsColor ? '\x1b[33m' : '', // Additional colors as needed +} as const;This implementation:
- Adds documentation
- Handles terminals without color support
- Uses const assertion for type safety
config/networks.json (1)
Line range hint
444-449
: Complete the opbnb network configurationThe opbnb network configuration appears incomplete:
safeAddress
is set butsafeApiUrl
is emptyexplorerApiUrl
is missing- Network is marked as "inactive"
This might affect the functionality of safe-related operations on the opbnb network.
Please provide the missing API URLs or document why they are intentionally left empty.
script/deploy/safe/confirm-safe-tx.ts (1)
64-67
: Consider usinggetAllActiveNetworks
to avoid duplicationThe logic used here to filter active networks duplicates the functionality of the
getAllActiveNetworks
function imported fromviemScriptHelpers
. To adhere to the DRY (Don't Repeat Yourself) principle and improve maintainability, consider usinggetAllActiveNetworks()
directly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
config/networks.json
(34 hunks)lib/openzeppelin-contracts
(1 hunks)script/deploy/safe/confirm-safe-tx.ts
(8 hunks)script/utils/viemScriptHelpers.ts
(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- lib/openzeppelin-contracts
🔇 Additional comments (11)
script/utils/viemScriptHelpers.ts (1)
23-23
: LGTM! Verify network configurations include safeWebUrl
The new safeWebUrl
property is properly typed and aligns with the PR's objective of improving safe transaction handling.
Let's verify that all active networks have this property configured:
✅ Verification successful
All active networks have safeWebUrl configured correctly
After verifying the networks.json file, all active networks (status: "active") have the safeWebUrl property properly configured with valid URLs pointing to their respective Safe transaction queues. The property is consistently present and follows the expected format across all active chains.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if all active networks have safeWebUrl configured
# Expected: All active networks should have a valid safeWebUrl
jq -r '
to_entries[] |
select(.value.status == "active") |
select(.value.safeWebUrl == null or .value.safeWebUrl == "") |
.key
' config/networks.json
Length of output: 162
Script:
#!/bin/bash
# Let's first check if the networks.json file exists and see its content
fd -t f "networks.json" --exec cat {}
Length of output: 27387
config/networks.json (1)
286-287
: Verify the reuse of safeAddress across networks
Multiple networks are using the same safeAddress: 0xa89a87986e8ee1Ac8fDaCc5Ac91627010Ec9f772
This appears in configurations for:
- immutablezkevm
- kaia
- fraxtal
- cronos
- taiko
Please verify if this address reuse is intentional and document the reason if it is.
Also applies to: 304-305
✅ Verification successful
Let me gather more context about the network configurations to understand if this is a pattern or an isolated case.
From the output, I can now see a clear pattern. There are actually two groups of networks sharing the same safeAddress:
0xa89a87986e8ee1Ac8fDaCc5Ac91627010Ec9f772
: Used by celo, cronos, fraxtal, immutablezkevm, kaia, mantle, and taiko0xdf61270fDC1A892874Fd3C0143A0A4CBA74F4EF1
: Used by blast, linea, mode, rootstock, scroll, and sei
Let me check if there's any configuration or deployment related code that might explain this pattern.
Based on the findings from the codebase, I can now provide a conclusive response:
Safe address reuse appears to be intentional for newer/emerging networks
The shared safe addresses represent two distinct deployment groups:
0xa89a87986e8ee1Ac8fDaCc5Ac91627010Ec9f772
: Used for newer L2/emerging networks (celo, cronos, fraxtal, immutablezkevm, kaia, mantle, taiko)0xdf61270fDC1A892874Fd3C0143A0A4CBA74F4EF1
: Used for another group of emerging networks (blast, linea, mode, rootstock, scroll, sei)
While established networks (mainnet, arbitrum, polygon, etc.) have their unique safe addresses, this pattern of address reuse appears to be a deliberate deployment strategy for newer networks, as evidenced by the deployment scripts and configuration in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all networks sharing the same safeAddress
# Search for the repeated safeAddress
echo "Networks sharing safeAddress 0xa89a87986e8ee1Ac8fDaCc5Ac91627010Ec9f772:"
rg -B 2 -A 1 '"safeAddress": "0xa89a87986e8ee1Ac8fDaCc5Ac91627010Ec9f772"' config/networks.json
Length of output: 2484
Script:
#!/bin/bash
# Let's examine the overall structure of networks.json and look for other safeAddress patterns
echo "Analyzing all safeAddress configurations:"
jq -r 'to_entries[] | select(.value.safeAddress != null) | "\(.key): \(.value.safeAddress)"' config/networks.json | sort
echo -e "\nChecking if there's any documentation about safe addresses:"
rg -i "safe.*(address|config)" --type md
Length of output: 2102
Script:
#!/bin/bash
# Look for any deployment scripts or configuration logic related to safe addresses
echo "Searching for safe address related code:"
rg -i "safeAddress|safe.*deploy" --type ts --type js -C 2
echo -e "\nChecking for any environment variables related to safe:"
rg -i "SAFE.*ADDRESS" --type env --type ts --type js
Length of output: 6600
script/deploy/safe/confirm-safe-tx.ts (9)
110-121
: Good practice: Enhanced error handling when initializing SafeApiKit
Adding a try-catch
block around the initialization of safeService
improves the robustness of the script by gracefully handling potential errors and preventing crashes.
139-153
: Good practice: Enhanced error handling when setting up ProtocolKit
The inclusion of a try-catch
block during the setup of protocolKit
ensures that any initialization errors are properly caught and handled, enhancing the script's stability.
155-167
: Good practice: Improved error handling when fetching pending transactions
Wrapping the call to safeService.getPendingTransactions
in a try-catch
block effectively handles API errors and prevents the script from terminating unexpectedly.
171-189
: Enhanced error handling in signTransaction
function
Passing safeWebUrl
as a parameter allows error messages to include a direct link for users to troubleshoot issues via the SAFE web interface. The updated error handling enhances user experience and guidance.
195-213
: Improved error handling in executeTransaction
function
Incorporating safeWebUrl
into the error messages provides users with immediate access to the relevant SAFE web page in case of execution failures. This makes troubleshooting more efficient.
304-306
: Correctly updated function call in 'Sign' action
The signTransaction
function now correctly includes safeWebUrl
as an argument, ensuring that enhanced error messages are available during the sign action.
310-313
: Correctly updated function calls in 'Sign & Execute Now' action
Both signTransaction
and executeTransaction
are called with safeWebUrl
, maintaining consistency and ensuring enhanced error handling during the combined action.
317-319
: Correctly updated function call in 'Execute Now' action
The executeTransaction
function is invoked with safeWebUrl
, aligning with the updated function signature and ensuring helpful error messaging.
101-101
: Verify that safeWebUrl
is defined for all active networks
To prevent potential runtime errors when accessing safeWebUrl
, ensure that this property is defined for all active networks in networks.json
.
Run the following script to check for active networks missing safeWebUrl
:
✅ Verification successful
safeWebUrl
is defined for all active networks
After examining the networks.json file, I can confirm that all networks with "status": "active"
have a properly defined safeWebUrl
property. The only networks missing or having empty safeWebUrl
are those marked as "status": "inactive"
, such as "gravity", "immutablezkevm", "opbnb", and "localanvil", which are not relevant to this verification since they are not active networks.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for active networks without 'safeWebUrl' defined in 'networks.json'.
# Expected result: No active network should be missing 'safeWebUrl'.
jq -r '. | to_entries[] | select(.value.status=="active" and (.value.safeWebUrl == null or .value.safeWebUrl == "")) | .key' config/networks.json
Length of output: 147
Script:
#!/bin/bash
# First, let's check if the networks.json file exists and see its content
cat config/networks.json 2>/dev/null || find . -type f -name "networks.json" | xargs cat
Length of output: 27374
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…e/contracts into addNetworkToConfirmSafeTxScript
Which Jira task belongs to this PR?
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)