Feat/syn bridge unified [SYN-91] #334
Conversation
WalkthroughThis update introduces a governance-controlled mechanism to disable legacy send operations in the SynapseBridge contract, removes the gas airdrop feature, and refactors mint and withdraw logic into internal functions. Multiple new and refactored tests validate legacy send gating, fee withdrawal, reentrancy protection, upgrade safety, and proxy deployment. Changes
Sequence Diagram(s)sequenceDiagram
participant Governance
participant SynapseBridge
participant User
Governance->>SynapseBridge: setLegacySendDisabled(true/false)
Note right of SynapseBridge: Update isLegacySendDisabled flag and emit event
User->>SynapseBridge: deposit/redeem/legacy send functions
alt isLegacySendDisabled == false
SynapseBridge->>User: Process legacy send function
else isLegacySendDisabled == true
SynapseBridge-->>User: revert "Legacy send is disabled"
end
sequenceDiagram
participant Governance
participant SynapseBridge
Governance->>SynapseBridge: withdrawChainGas()
SynapseBridge->>Governance: Transfer ETH balance
SynapseBridge->>Governance: Emit ChainGasWithdrawn event
Possibly related PRs
Poem
✨ Finishing Touches
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. 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 (
|
🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Pull Request Test Coverage Report for Build 15958101691Details
💛 - Coveralls |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
contracts/bridge/SynapseBridge.sol (2)
57-61: New governance function to withdraw ETH balanceThis function allows governance to withdraw the entire ETH balance from the contract. The implementation correctly:
- Restricts access to governance
- Uses a low-level call with value to transfer all ETH
- Checks for transfer success
Consider adding an event emission to log ETH withdrawals for transparency and auditing purposes.
function withdrawChainGas() external { require(hasRole(GOVERNANCE_ROLE, msg.sender), "Not governance"); + uint256 amount = address(this).balance; (bool success, ) = msg.sender.call{value: address(this).balance}(""); require(success, "ETH_TRANSFER_FAILED"); + emit ChainGasWithdrawn(msg.sender, amount); }
63-66: Governance function to toggle legacy send featureThis function provides governance with the ability to enable or disable legacy send functionality. An event emission would be valuable here as well to track when this setting changes.
function setLegacySendDisabled(bool _isLegacySendDisabled) external { require(hasRole(GOVERNANCE_ROLE, msg.sender), "Not governance"); isLegacySendDisabled = _isLegacySendDisabled; + emit LegacySendStatusChanged(_isLegacySendDisabled); }test/bridge/legacy/SynapseBridge.t.sol (1)
1-306: Verify test coverage with actual manual callsWhile the test file comprehensively verifies event emissions and function access, it doesn't validate the actual effects of function calls (e.g., token transfers, balance changes). Consider enhancing the tests to verify state changes after function calls.
For example, in
test_deposit(), verify that tokens were actually transferred from the user to the bridge by checking balances before and after the call.function test_deposit() public { + uint256 userBalanceBefore = token.balanceOf(user); + uint256 bridgeBalanceBefore = token.balanceOf(address(bridge)); vm.expectEmit(address(bridge)); emit TokenDeposit({to: address(1), chainId: 2, token: address(token), amount: 3}); vm.prank(user); bridge.deposit({to: address(1), chainId: 2, token: IERC20(address(token)), amount: 3}); + assertEq(token.balanceOf(user), userBalanceBefore - 3, "User balance should decrease"); + assertEq(token.balanceOf(address(bridge)), bridgeBalanceBefore + 3, "Bridge balance should increase"); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/coveralls.yaml(1 hunks).github/workflows/test.yaml(2 hunks)contracts/bridge/SynapseBridge.sol(8 hunks)test/bridge/legacy/SynapseBridge.t.sol(1 hunks)
🔇 Additional comments (10)
.github/workflows/coveralls.yaml (1)
34-34: Cache action upgraded to v4
Consistent with other CI workflows,actions/cachehas been updated fromv2tov4. No other changes needed..github/workflows/test.yaml (2)
54-54: Cache action upgraded in foundry-base
The step for caching npm modules now usesactions/cache@v4, matching the Coveralls workflow.
85-85: Cache action upgraded in foundry-integration
Same update applied here (actions/cache@v4) to maintain consistency across all jobs.contracts/bridge/SynapseBridge.sol (3)
32-37: Bridge version incremented and new state variable addedThe bridge version has been incremented from 6 to 8, and a new boolean state variable
isLegacySendDisabledhas been introduced to control legacy send functions. This strategy allows for graceful deprecation of legacy functionality while maintaining backward compatibility.
39-42: Well-designed modifier for toggling legacy send functionalityThe
legacySendEnabledmodifier provides a clean way to gate legacy functions. This approach is better than adding the same check to each function body, following the DRY principle and making the code more maintainable.
187-187: Legacy send modifier correctly applied to all relevant functionsThe
legacySendEnabledmodifier has been consistently applied to all legacy send functions:deposit,redeem,depositAndSwap,redeemAndSwap,redeemAndRemove, andredeemV2. This ensures that all legacy functions can be disabled together when needed.Also applies to: 204-204, 286-286, 311-311, 334-334, 539-539
test/bridge/legacy/SynapseBridge.t.sol (4)
1-64: Well-structured test setupThe test file follows good practices:
- Proper importing of contracts under test
- Clear test contract organization with helper functions
- Appropriate event declarations matching the bridge contract
- Comprehensive setup with token initialization and approvals
The test setup provides a solid foundation for testing the legacy send functionality.
66-92: Comprehensive tests for legacy send toggleThe tests thoroughly verify:
- Disabling legacy send works as expected
- Re-enabling legacy send works as expected
- Only governance can toggle the setting
These tests provide good coverage of the new feature's access control and state changes.
94-107: Thorough testing of chain gas withdrawalThe tests validate:
- Successful withdrawal by governance
- Proper transfer of exact ETH balance
- Access control preventing non-governance calls
The test coverage for this feature is thorough and effective.
109-305: Comprehensive testing of all legacy send functionsFor each legacy function (
deposit,depositAndSwap,redeem,redeemAndSwap,redeemAndRemove,redeemV2), the tests verify:
- Normal operation when legacy send is enabled
- Successful reversion to enabled state after being disabled
- Proper reversion with expected error message when disabled
This pattern is consistently applied across all functions, providing thorough test coverage. The use of
vm.expectEmitto verify event emissions is particularly valuable.
* fix: update old tests for foundry 1.0 * fix: update integration tests to 1.0
SYN-100: legacy workflows for mint and withdraw
SYN-102: withdraw fees
* test: new events * test: setChainGasAmount should revert * fix: new events, setChainGasAmount revert * test: upgrade storage values * fix: properly deprecate chainGasAmount * refactor: separate constants vs storage
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
test/bridge/legacy/SynapseBridge.Upgrade.t.sol (1)
11-12: Address the TODO comment about test namingThe TODO indicates this contract should be renamed to
TestForkto exclude it from CI workflow post-migration. This should be tracked to ensure proper CI configuration.Would you like me to create an issue to track this renaming task?
contracts/bridge/SynapseBridge.sol (1)
29-30: Version increment appears excessive.The bridge version jumps from (presumably) 6 to 8, skipping version 7. This could indicate missing intermediate changes or inconsistent versioning.
Consider using incremental versioning or document why version 7 was skipped if intentional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
contracts/bridge/SynapseBridge.sol(14 hunks)test/bridge/legacy/PoolMock.sol(1 hunks)test/bridge/legacy/ReenteringToken.sol(1 hunks)test/bridge/legacy/SynapseBridge.Dst.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.Fees.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.Upgrade.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.t.sol(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- test/bridge/legacy/SynapseBridge.t.sol
🧰 Additional context used
🪛 Gitleaks (8.26.0)
test/bridge/legacy/SynapseBridge.Upgrade.t.sol
24-24: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (15)
test/bridge/legacy/ReenteringToken.sol (1)
32-40: Good reentrancy implementation patternThe implementation correctly clears the reentrancy state before making the external call, preventing multiple reentrancies. Using
Address.functionCallis appropriate for this use case.test/bridge/legacy/SynapseBridge.Upgrade.t.sol (1)
24-24: Static analysis false positive - no action neededThe static analysis tool incorrectly flagged the Ethereum address as an API key. This is a false positive and can be safely ignored.
test/bridge/legacy/SynapseBridge.Dst.t.sol (1)
1-339: Excellent comprehensive test coverageThis test suite thoroughly covers destination-side bridge functionality including:
- All operation variants (mint, mintAndSwap, withdraw, withdrawAndRemove)
- Edge cases and error conditions
- Reentrancy protection validation
- Access control enforcement
- Legacy send disabled behavior
- Proper event emission verification
The modular structure with helper functions and modifiers makes the tests readable and maintainable.
test/bridge/legacy/SynapseBridge.Fees.t.sol (1)
48-56: Well-designed reentrancy testThe reentrancy test cleverly verifies that attempting to withdraw fees again during a reentrant call results in no additional withdrawal (since fees are already zeroed). This confirms the contract's reentrancy protection works correctly.
contracts/bridge/SynapseBridge.sol (11)
35-36: Good practice: Preventing storage slot gaps.The deprecation comment and storage variable properly maintain storage layout compatibility during upgrades.
40-45: Well-implemented access control modifier.The
isLegacySendDisabledstate variable andlegacySendEnabledmodifier provide clean governance control over legacy functionality with clear error messaging.
55-57: Gas airdrop functionality properly disabled.The function correctly prevents any changes to gas amounts by reverting with a clear message, effectively disabling the gas airdrop feature.
66-70: Governance function properly implemented.The
setLegacySendDisabledfunction correctly restricts access to governance and emits appropriate events for transparency.
144-146: Event definitions are appropriate.The new governance events provide proper logging for legacy send state changes and chain gas withdrawals.
166-170: Improved fee withdrawal logic.Caching the fee amount before zeroing prevents potential reentrancy issues and ensures accurate transfer amounts.
196-196: Legacy send modifiers correctly applied.All legacy send functions (
deposit,redeem,depositAndSwap,redeemAndSwap,redeemAndRemove,redeemV2) are properly gated with thelegacySendEnabledmodifier.Also applies to: 213-213, 323-323, 348-348, 371-371, 584-584
236-237: Good refactoring to extract common logic.The
withdrawandmintfunctions are properly refactored to delegate to internal functions, maintaining the same external interface while enabling code reuse.Also applies to: 282-283
239-261: Internal functions properly implemented.The
_withdrawand_mintinternal functions extract the core logic without access control checks, which is appropriate since security checks are handled in the calling functions.Also applies to: 285-301
405-408: Fallback logic correctly implemented.The
mintAndSwapandwithdrawAndRemovefunctions properly check the legacy send state and fallback to simpler internal functions when legacy workflows are disabled, maintaining functionality while bypassing complex swap logic.Also applies to: 513-516
59-64: Verify ETH transfer security.The governance-only
withdrawChainGasfunction uses low-level call for ETH transfer, which is correct, but ensure the governance role is properly secured.Run the following script to verify that the GOVERNANCE_ROLE is properly configured and that similar ETH transfer patterns are used consistently:
#!/bin/bash # Description: Check for governance role usage and ETH transfer patterns # Search for GOVERNANCE_ROLE usage patterns echo "=== GOVERNANCE_ROLE Usage ===" rg -A 2 -B 2 "GOVERNANCE_ROLE" # Search for low-level ETH transfer patterns echo "=== ETH Transfer Patterns ===" rg -A 2 -B 2 "\.call\{value:"
* test: use proxy in tests, impl initialize must revert * fix: prevent impl from being initialized * test: update older tests to use proxy pattern
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
test/bridge/legacy/SynapseBridge.Proxy.t.sol (1)
15-19: Consider adding documentation for the proxy testing pattern.The setUp method establishes a proxy testing pattern that other tests inherit. Consider adding a comment explaining why tests use minimal proxies instead of the actual proxy structure used in production.
function setUp() public virtual { implementation = address(new SynapseBridge()); - // Tests don't need to assume the exact proxy structure, so we can use a minimal proxy. + // Tests use minimal proxies (EIP-1167) for simplicity. This provides the same + // initialization behavior as production proxies while avoiding complexity of + // specific proxy implementations (transparent, UUPS, etc). bridge = SynapseBridge(payable(Clones.clone(implementation))); }test/bridge/legacy/SynapseBridge.Dst.t.sol (1)
91-92: Document or fix the legacy fee emission behavior.The comment indicates that
TokenWithdrawemits the amount before fees are deducted, which differs from the actual transfer amount. This inconsistency could cause confusion for event consumers.Consider either:
- Documenting this as intentional legacy behavior in the main contract
- Creating a new event that emits the post-fee amount for better clarity
- Adding a migration plan to fix this in a future version
contracts/bridge/SynapseBridge.sol (1)
40-45: Consider naming clarity for the boolean flag.The implementation is correct, but the double-negative logic (
!isLegacySendDisabled) might be confusing. Consider renaming toisLegacySendEnabledfor better readability, though the current implementation is functionally correct.-bool public isLegacySendDisabled; +bool public isLegacySendEnabled; -modifier legacySendEnabled() { - require(!isLegacySendDisabled, "Legacy send is disabled"); +modifier legacySendEnabled() { + require(isLegacySendEnabled, "Legacy send is disabled");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
contracts/bridge/SynapseBridge.sol(14 hunks)test/bridge/legacy/SynapseBridge.Dst.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.Fees.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.Proxy.t.sol(1 hunks)test/bridge/legacy/SynapseBridge.t.sol(1 hunks)test/bridge/wrappers/MockSwap.t.sol(2 hunks)test/utils/Utilities06.sol(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- test/bridge/legacy/SynapseBridge.Fees.t.sol
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: Build
- GitHub Check: test
- GitHub Check: hardhat-test
- GitHub Check: foundry-integration
- GitHub Check: foundry-base
- GitHub Check: Build
- GitHub Check: test
- GitHub Check: foundry-integration
- GitHub Check: foundry-base
- GitHub Check: hardhat-test
🔇 Additional comments (20)
test/bridge/wrappers/MockSwap.t.sol (1)
12-13: LGTM! Correct implementation of proxy deployment pattern.The change properly deploys SynapseBridge as a minimal proxy clone, which aligns with the upgradeable contract design. The implementation contract is correctly left uninitialized, and only the proxy instance is initialized.
Also applies to: 24-25
test/utils/Utilities06.sol (1)
18-18: LGTM! Consistent proxy deployment pattern.The utility function correctly implements the same proxy deployment pattern, ensuring consistency across the test suite.
Also applies to: 189-190
test/bridge/legacy/SynapseBridge.Proxy.t.sol (1)
21-24: Good security test for implementation initialization.This test correctly verifies that the implementation contract cannot be initialized directly, which is a critical security check for the proxy pattern.
test/bridge/legacy/SynapseBridge.Dst.t.sol (1)
126-337: Excellent comprehensive test coverage.The test suite thoroughly covers:
- Normal operations (mint, withdraw with/without swaps)
- Edge cases (reverting pools, legacy send disabled)
- Security concerns (reentrancy protection, access control)
- State consistency (balance checks, fee accounting)
This provides strong confidence in the contract's behavior.
test/bridge/legacy/SynapseBridge.t.sol (3)
78-323: Comprehensive test coverage for legacy send functionality.The tests thoroughly validate:
- Governance-controlled legacy send toggling
- All legacy bridge functions in enabled/disabled states
- Access control for governance functions
- Event emissions for state changes
This provides excellent coverage of the new governance features.
117-125: Good validation of disabled gas airdrop feature.The tests confirm that
setChainGasAmountalways reverts, effectively disabling the gas airdrop feature as mentioned in the AI summary. This is a good security practice if the feature is no longer needed.
1-324: Note: Coverage reporting discrepancyWhile these test files appear to provide comprehensive coverage for the SynapseBridge contract changes, the PR comments indicate 0% coverage for the main contract. This suggests a potential issue with:
- Test execution configuration
- Coverage tool setup
- Contract deployment method affecting coverage tracking
Consider investigating why the coverage tool isn't detecting these tests.
contracts/bridge/SynapseBridge.sol (13)
29-30: LGTM! Version bump and gas airdrop removal are correctly implemented.The version bump to 8 and converting
chainGasAmountto a constant 0 effectively disables the gas airdrop feature as intended.
35-36: Good practice for upgradeable contracts.Maintaining the storage slot with a deprecated variable prevents storage layout conflicts during contract upgrades.
47-48: Excellent security practice for upgradeable contracts.Adding the
initializermodifier to the constructor prevents the implementation contract from being initialized directly, which is a security best practice.
58-60: LGTM! Function correctly blocks gas airdrop configuration.The function maintains backward compatibility while preventing gas amount configuration, aligning with the gas airdrop removal objective.
69-73: LGTM! Clean governance control implementation.The function provides proper access control and event emission for toggling legacy send functionality.
169-173: Good optimization for gas efficiency and security.Storing the fee amount in a local variable before clearing prevents potential reentrancy issues and saves gas by avoiding multiple storage reads.
199-199: Consistent application of legacy send gating.All legacy send functions correctly include the
legacySendEnabledmodifier, providing consistent control over legacy operations.Also applies to: 216-216, 326-326, 351-351, 374-374, 587-587
239-264: Well-structured refactoring following security best practices.The separation of validation logic (in public function) from execution logic (in internal function) is a good pattern that enables code reuse while maintaining security boundaries.
285-304: Consistent refactoring with gas airdrop removal.The mint function follows the same secure refactoring pattern as withdraw, and the internal
_mintfunction correctly removes the deprecated gas airdrop logic.
408-411: Smart fallback mechanism for graceful degradation.The fallback to simple
_mintwhen legacy sends are disabled provides graceful degradation while maintaining core functionality.
516-519: Consistent fallback implementation.The fallback to
_withdrawmaintains consistency with themintAndSwapfunction's fallback pattern, ensuring predictable behavior when legacy sends are disabled.
147-149: Proper event declarations for governance transparency.The new events provide appropriate transparency for governance actions with clear naming and parameter structure.
62-67: To ensure we accurately determine whetherwithdrawChainGasis protected against reentrancy, let’s locate its definition and check for anyReentrancyGuardinheritance ornonReentrantmodifier usage:#!/bin/bash # 1. Show the function definition in context rg -n "withdrawChainGas" -A3 -B3 # 2. Check if the contract imports or inherits a reentrancy guard rg -n "ReentrancyGuard" # 3. Look for any nonReentrant modifier usage across the repo rg -n "nonReentrant"
* feat: add deployment script for consistent impl address * feat: bash utility to run on all chains
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
script/bridge/DeploySynapseBridge.s.sol (1)
12-13: Address the TODO: Consider mining an optimal CREATE2 salt.Using a zero salt for CREATE2 deployment may not be optimal for gas efficiency or address vanity. Consider mining a salt that produces a desirable address prefix.
The current zero salt works functionally but may not be optimal. Would you like me to help generate a script to mine a CREATE2 salt for a vanity address?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
foundry.toml(1 hunks)script/bridge/DeploySynapseBridge.s.sol(1 hunks)script/bridge/deploy-implementation.sh(1 hunks)script/templates/BasicUtils.sol(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- foundry.toml
🧰 Additional context used
🪛 Shellcheck (0.10.0)
script/bridge/deploy-implementation.sh
[error] 25-25: Iterating over ls output is fragile. Use globs.
(SC2045)
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: foundry-integration
- GitHub Check: foundry-base
- GitHub Check: hardhat-test
- GitHub Check: Build
- GitHub Check: test
- GitHub Check: Build
- GitHub Check: foundry-integration
- GitHub Check: foundry-base
- GitHub Check: test
- GitHub Check: hardhat-test
🔇 Additional comments (5)
script/bridge/deploy-implementation.sh (2)
1-17: LGTM: Good script structure and validation.The script has proper argument validation, error handling, and user-friendly output with color coding.
19-21: LGTM: Robust project root resolution.The script correctly resolves the project root and ensures it runs from the correct directory.
script/bridge/DeploySynapseBridge.s.sol (3)
15-22: LGTM: Good early exit logic.The script correctly checks if SynapseBridge is deployed before proceeding, preventing unnecessary operations.
23-31: LGTM: Proper CREATE2 deployment pattern.The deployment logic correctly predicts the address, deploys using CREATE2, and saves the deployment with a clear alias.
32-35: LGTM: Essential verification logic.The address verification ensures the deployed contract matches the predicted address, which is crucial for CREATE2 deployments.
| // Example: jq .abi=$data[0].abi --slurpfile data path/to/input.json path/to/output.json | ||
| string[] memory inputs = new string[](6); | ||
| inputs[0] = "jq"; | ||
| inputs[1] = key.concat(" = $data", key); | ||
| inputs[2] = "--argfile"; | ||
| inputs[1] = key.concat(" = $data[0]", key); | ||
| inputs[2] = "--slurpfile"; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the JSON structure change is consistent across the codebase.
The change from --argfile to --slurpfile with array access ($data[0]) suggests the input JSON structure has changed from a single object to an array format. Ensure this change aligns with how JSON artifacts are generated and consumed elsewhere in the codebase.
🏁 Script executed:
#!/bin/bash
# Verify usage of addJsonKey function and related JSON processing
rg -A 3 -B 3 "addJsonKey|--argfile|--slurpfile" --type sol --type shLength of output: 98
To ensure we capture all occurrences regardless of file-type mappings, let’s drop the --type filters and use globs instead:
🏁 Script executed:
#!/bin/bash
# Search for JSON key helper usage and jq flags across Solidity and shell scripts
rg -A3 -B3 "addJsonKey|--argfile|--slurpfile" -g '*.sol' -g '*.sh'Length of output: 2567
Inconsistent jq flag usage in DeployScript.sol
The helper in BasicUtils.sol now uses --slurpfile with array indexing ($data[0]), but script/utils/DeployScript.sol still uses --argfile and accesses $artifact.abi. This will break JSON handling. Please update:
• File: script/utils/DeployScript.sol
--- a/script/utils/DeployScript.sol
@@ (inside function that builds jq inputs)
- inputs[1] = "--argfile";
+ inputs[1] = "--slurpfile";
inputs[2] = "artifact";
inputs[3] = _artifactPath(contractName);
- inputs[4] = ".abi = $artifact.abi";
+ inputs[4] = ".abi = $artifact[0].abi";
inputs[5] = path;This aligns both scripts to handle the input JSON as an array.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Example: jq .abi=$data[0].abi --slurpfile data path/to/input.json path/to/output.json | |
| string[] memory inputs = new string[](6); | |
| inputs[0] = "jq"; | |
| inputs[1] = key.concat(" = $data", key); | |
| inputs[2] = "--argfile"; | |
| inputs[1] = key.concat(" = $data[0]", key); | |
| inputs[2] = "--slurpfile"; | |
| // inside function that builds jq inputs in script/utils/DeployScript.sol | |
| inputs[1] = "--slurpfile"; | |
| inputs[2] = "artifact"; | |
| inputs[3] = _artifactPath(contractName); | |
| inputs[4] = ".abi = $artifact[0].abi"; | |
| inputs[5] = path; |
🤖 Prompt for AI Agents
In script/utils/DeployScript.sol around the lines where jq is used with
--argfile and $artifact.abi, update the jq command to use --slurpfile instead of
--argfile and change the JSON access from $artifact.abi to $data[0].abi to match
the array handling in BasicUtils.sol. This ensures consistent JSON input
handling across both scripts.
| for chainName in $(ls deployments); do | ||
| if [ -f "deployments/$chainName/SynapseBridge.json" ]; then | ||
| ./script/run.sh ./script/bridge/DeploySynapseBridge.s.sol "$chainName" "$WALLET_NAME" "$@" | ||
| fi | ||
| done |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix: Use robust iteration pattern instead of ls output.
The current approach of iterating over ls output can be fragile with filenames containing spaces or special characters.
-for chainName in $(ls deployments); do
+for chainName in deployments/*/; do
+ chainName=$(basename "$chainName")
if [ -f "deployments/$chainName/SynapseBridge.json" ]; then
./script/run.sh ./script/bridge/DeploySynapseBridge.s.sol "$chainName" "$WALLET_NAME" "$@"
fi
done📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for chainName in $(ls deployments); do | |
| if [ -f "deployments/$chainName/SynapseBridge.json" ]; then | |
| ./script/run.sh ./script/bridge/DeploySynapseBridge.s.sol "$chainName" "$WALLET_NAME" "$@" | |
| fi | |
| done | |
| for chainName in deployments/*/; do | |
| chainName=$(basename "$chainName") | |
| if [ -f "deployments/$chainName/SynapseBridge.json" ]; then | |
| ./script/run.sh ./script/bridge/DeploySynapseBridge.s.sol "$chainName" "$WALLET_NAME" "$@" | |
| fi | |
| done |
🧰 Tools
🪛 Shellcheck (0.10.0)
[error] 25-25: Iterating over ls output is fragile. Use globs.
(SC2045)
🤖 Prompt for AI Agents
In script/bridge/deploy-implementation.sh around lines 25 to 29, replace the for
loop that iterates over the output of `ls deployments` with a more robust
pattern such as a glob pattern or a while loop using `find` or `readarray` to
safely handle directory names with spaces or special characters. This avoids
issues caused by word splitting and ensures reliable iteration over the
deployment directories.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Tests
Chores