fix(bootstrap): do not fail mark bootstrap #90
Conversation
- As outlined in ExocoreNetwork#83, a cross-chain message that can't/won't be retried must not fail. Hence, all calls to `markBootstrapped` on `Bootstrap` should not fail. Fixes ExocoreNetwork#89 - Separately, sending multiple LZ messages in one transaction is convoluted and hence disabled. As a consequence, marking bootstrap on all chains is no longer supported; instead, the caller must provide the LZ chain ID. Along similar lines, the caller must provide the native fee for this transaction.
WalkthroughThe changes involve significant modifications to the contracts related to the bootstrap process across multiple chains. Key updates include the introduction of new functions for marking bootstraps, enhancements in error handling, and a shift towards a fee-based structure for client chain interactions. Additionally, the initialization processes have been refined, and several redundant elements have been removed to streamline the functionality. Changes
Assessment against linked issues
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 (
|
![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
Outside diff range, codebase verification and nitpick comments (2)
test/mocks/ExocoreGatewayMock.sol (2)
110-118: Looks good, but consider removing thepayablemodifier and handling the failure case of_markBootstrapcall.The code changes are approved with a few suggestions:
- The function is marked as
payable, which is not necessary as it doesn't receive any Ether. Consider removing thepayablemodifier.- The function doesn't handle the failure case of
_markBootstrapcall. Consider adding a check for the success of_markBootstrapcall and reverting with a specific error if it fails.
120-122: Looks good, but consider removing thepayablemodifier and handling the failure case of_markBootstrapcall.The code changes are approved with a few suggestions:
- The function is marked as
payable, which is not necessary as it doesn't receive any Ether. Consider removing thepayablemodifier.- The function doesn't handle the failure case of
_markBootstrapcall. Consider adding a check for the success of_markBootstrapcall and reverting with a specific error if it fails.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (13)
- script/11_SetPeers.s.sol (2 hunks)
- script/14_CorrectBootstrapErrors.s.sol (3 hunks)
- script/7_DeployBootstrap.s.sol (3 hunks)
- script/integration/1_DeployBootstrap.s.sol (1 hunks)
- src/core/Bootstrap.sol (4 hunks)
- src/core/ExocoreGateway.sol (1 hunks)
- src/interfaces/IExocoreGateway.sol (1 hunks)
- src/libraries/Errors.sol (1 hunks)
- src/storage/BootstrapStorage.sol (1 hunks)
- src/storage/ExocoreGatewayStorage.sol (1 hunks)
- test/foundry/unit/Bootstrap.t.sol (9 hunks)
- test/foundry/unit/ExocoreGateway.t.sol (1 hunks)
- test/mocks/ExocoreGatewayMock.sol (1 hunks)
Files skipped from review due to trivial changes (1)
- src/libraries/Errors.sol
Additional context used
Learnings (6)
script/14_CorrectBootstrapErrors.s.sol (1)
Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.script/integration/1_DeployBootstrap.s.sol (1)
Learnt from: adu-web3 PR: ExocoreNetwork/exocore-contracts#23 File: script/integration/1_DeployBootstrap.s.sol:19-19 Timestamp: 2024-06-18T08:22:01.846Z Learning: The `1_DeployBootstrap.s.sol` script in the Exocore contracts repository is intended for testing purposes, and its import paths, such as for `MyToken`, are structured accordingly.test/mocks/ExocoreGatewayMock.sol (1)
Learnt from: adu-web3 PR: ExocoreNetwork/exocore-contracts#23 File: test/mocks/ExocoreGatewayMock.sol:0-0 Timestamp: 2024-06-17T07:43:43.986Z Learning: User adu-web3 suggests that the `chainToBootstrapped[clientChainId]` marking in `ExocoreGatewayMock.sol` has no significant effects beyond setting a state and that synchronization issues are currently not a concern. They are open to implementing a response check in the future if necessary.src/core/Bootstrap.sol (1)
Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.test/foundry/unit/ExocoreGateway.t.sol (2)
Learnt from: adu-web3 PR: ExocoreNetwork/exocore-contracts#23 File: test/mocks/ExocoreGatewayMock.sol:0-0 Timestamp: 2024-06-17T07:43:43.986Z Learning: User adu-web3 suggests that the `chainToBootstrapped[clientChainId]` marking in `ExocoreGatewayMock.sol` has no significant effects beyond setting a state and that synchronization issues are currently not a concern. They are open to implementing a response check in the future if necessary.Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.test/foundry/unit/Bootstrap.t.sol (1)
Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.
Additional comments not posted (38)
script/11_SetPeers.s.sol (2)
5-5: LGTM!The import statement for
GatewayStorageis correctly added.
57-59: LGTM!The code segment correctly calculates the
nativeFeeusing thequotemethod from theexocoreGatewayand passes it as a value to themarkBootstrapfunction call. This change streamlines the process of marking the bootstrap across all chains by directly utilizing a fee structure instead of a conditional funding mechanism, aligning with the objectives mentioned in the PR summary and linked issues.src/interfaces/IExocoreGateway.sol (1)
61-66: LGTM!The new
markBootstrapfunction declaration in theIExocoreGatewayinterface looks good:
- The function is properly declared as external and payable, aligning with its purpose of marking the network as bootstrapped on the client chain and requiring a fee to be paid to the LayerZero infrastructure.
- The function takes a single parameter
clientChainIdof typeuint32, representing the LayerZero chain ID of the client chain.- The function is well-documented with NatSpec comments that clearly explain its purpose, prerequisites, and operational details.
- The function declaration is consistent with the PR objectives and the AI-generated summary.
script/14_CorrectBootstrapErrors.s.sol (5)
32-32: LGTM!The addition of the
clientGatewayLogicstate variable is approved. It will be useful for storing the address of the client gateway logic contract.
33-33: LGTM!The addition of the
initializationstate variable is approved. It will be useful for storing the encoded initialization data for the client gateway.
67-68: LGTM!The changes to read the
clientGatewayLogicaddress from the configuration and include a requirement check for non-zero address are approved.These changes align with the learning from PR #16 about including checks for non-zero address in the
setClientChainGatewayLogicmethod. Good job on applying the learnings consistently!
69-69: LGTM!Populating the
initializationvariable with the encoded call to theinitializefunction of theClientChainGatewaycontract is approved. This ensures that the contract is correctly initialized during the upgrade process.
89-91: LGTM!The modifications to the
upgradeAndCallmethod invocation to include theproxyAdmin,clientGateway, andinitializationparameters are approved.These changes align with the PR objectives of introducing new functions for marking bootstraps and refining the initialization process. They enhance the upgrade mechanism by integrating additional logic for client gateway management and initialization, thereby improving the contract's operational robustness.
script/7_DeployBootstrap.s.sol (4)
63-73: LGTM!The code changes are approved. The necessary contracts for the client chain gateway are being deployed correctly, and the constructor parameters for
ClientChainGatewayare set appropriately.
75-77: LGTM!The code changes are approved. The initialization data for the
ClientChainGatewaycontract is correctly prepared usingabi.encodeWithSelector, passing the necessary parameters to theinitializefunction.
93-95: LGTM!The code changes are approved. The
proxyAdminaddress,clientGatewayLogicaddress, and theinitializationdata are correctly passed as constructor parameters for theBootstrapcontract.
Line range hint
114-118: LGTM!The code changes are approved. The addresses of the deployed contracts related to the client chain, including
capsuleImplementation,capsuleBeacon, andclientGatewayLogic, are correctly serialized usingvm.serializeAddressand stored in theclientChainContractsvariable.src/storage/ExocoreGatewayStorage.sol (1)
Line range hint
1-1: Verify the impact of removing thechainToBootstrappedmapping.The removal of the
chainToBootstrappedmapping is a significant change that can affect how the contract handles bootstrap requests and maintains a record of bootstrapped chains. Please ensure that:
- The contract's functionality is not adversely affected by the removal of this mapping.
- There is an alternative mechanism in place to track and manage bootstrap requests for client chains.
- The removal of this mapping does not introduce any unintended consequences or vulnerabilities.
To verify the impact of removing the mapping, consider running the following script:
Please review the output of the script and address any potential issues or concerns related to the removal of the
chainToBootstrappedmapping.Verification successful
Removal of
chainToBootstrappedMapping VerifiedThe removal of the
chainToBootstrappedmapping does not adversely affect the contract's functionality. Alternative mechanisms, such as themarkBootstrapfunction and related events and state variables, are in place to handle bootstrapping processes. Ensure that these mechanisms are thoroughly tested to prevent any unintended consequences or vulnerabilities.
- Consider reviewing the
markBootstrapfunction and related events to ensure they adequately replace the removed mapping's functionality.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: # This script searches for references to the removed `chainToBootstrapped` mapping # and its usage in the codebase to identify potential issues and ensure that the # contract's functionality is not adversely affected. # Test 1: Search for references to the removed mapping echo "Searching for references to the removed 'chainToBootstrapped' mapping..." rg --type solidity 'chainToBootstrapped' # Test 2: Search for code patterns that may be affected by the removal echo "Searching for code patterns that may be affected by the removal..." rg --type solidity -A 5 $'ExocoreGatewayStorage' | rg $'function|event|error' # Test 3: Search for alternative mechanisms to track and manage bootstrap requests echo "Searching for alternative mechanisms to track and manage bootstrap requests..." rg --type solidity -A 5 $'bootstrap'Length of output: 722
Script:
#!/bin/bash # Description: # This script searches for references to the removed `chainToBootstrapped` mapping # and its usage in the codebase to identify potential issues and ensure that the # contract's functionality is not adversely affected. # Test 1: Search for references to the removed mapping in Solidity files echo "Searching for references to the removed 'chainToBootstrapped' mapping..." rg 'chainToBootstrapped' --glob '*.sol' # Test 2: Search for code patterns that may be affected by the removal in Solidity files echo "Searching for code patterns that may be affected by the removal..." rg -A 5 'ExocoreGatewayStorage' --glob '*.sol' | rg 'function|event|error' # Test 3: Search for alternative mechanisms to track and manage bootstrap requests in Solidity files echo "Searching for alternative mechanisms to track and manage bootstrap requests..." rg -A 5 'bootstrap' --glob '*.sol'Length of output: 101425
script/integration/1_DeployBootstrap.s.sol (1)
133-135: Intentional changes for testing context. Verify no unintended side effects.The addition of
address(0x1)andbytes("123456")as parameters to thebootstrap.initializefunction call is noted to be irrelevant for the local network testing scenario, as per the comment.However, it's important to ensure that these changes don't introduce any unintended side effects or impact the contract's behavior in unexpected ways, even in the testing environment.
To verify that the added parameters don't introduce unintended side effects, you can run the following script:
This script searches for occurrences of the
bootstrap.initializefunction in the codebase and provides additional context around each match. Review the results to ensure that the added parameters are only used in the intended testing context and don't introduce unintended side effects in other parts of the system.Verification successful
Intentional changes confirmed for testing purposes. No unintended side effects found.
The addition of
address(0x1)andbytes("123456")to thebootstrap.initializefunction call is consistent across both the integration script and unit tests, indicating that these changes are intentional for specific test scenarios. The varied use of parameters in other test cases further supports that the testing framework is designed to handle different initialization scenarios, reducing the risk of unintended side effects.
- Files Reviewed:
script/integration/1_DeployBootstrap.s.soltest/foundry/unit/Bootstrap.t.solScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the added parameters to `bootstrap.initialize` don't introduce unintended side effects. # Test: Search for the `bootstrap.initialize` function usage in the codebase. # Expect: No occurrences outside the testing context where the added parameters might introduce unintended side effects. rg --type solidity -A 5 $'bootstrap\.initialize'Length of output: 82
Script:
#!/bin/bash # Description: Verify that the added parameters to `bootstrap.initialize` don't introduce unintended side effects. # Test: Search for the `bootstrap.initialize` function usage in the codebase. # Expect: No occurrences outside the testing context where the added parameters might introduce unintended side effects. rg -A 5 'bootstrap\.initialize'Length of output: 4773
test/mocks/ExocoreGatewayMock.sol (1)
124-128: LGTM!The code changes are approved.
src/storage/BootstrapStorage.sol (2)
230-232: LGTM!The
BootstrapNotTimeYetevent aligns with the PR objective of preventing bootstrap failures from disrupting the system by providing a mechanism to signal that the bootstrap process cannot proceed yet without treating it as an error.
234-237: LGTM!The
BootstrapUpgradeFailedevent aligns with the PR objective of ensuring bootstrap failures do not disrupt the overall system functionality by providing a mechanism to signal the failure of the bootstrap upgrade process without treating it as an error to prevent blocking the system.src/core/ExocoreGateway.sol (2)
101-106: LGTM!The code changes are approved.
108-114: LGTM!The code changes are approved.
src/core/Bootstrap.sol (4)
88-88: LGTM!The new parameters
clientChainGatewayLogic_andclientChainInitializationData_are being properly utilized in theinitializefunction to set up the client chain gateway.
552-578: LGTM!The changes to the
markBootstrappedfunction introduce more resilient error handling and align with the PR objectives:
- Emitting a
BootstrapNotTimeYetevent instead of reverting when the current block timestamp is less than the spawn time allows for more graceful handling of timing issues.- Using a
try-catchblock for the implementation upgrade and emitting aBootstrapUpgradeFailedevent on failure enables retries without causing the entire operation to fail.- Emitting the
Bootstrappedevent regardless of the upgrade success or failure ensures consistent event emission.These changes contribute to avoiding failures in the
markBootstrappedprocess and maintaining the integrity of the system.
Line range hint
595-613: LGTM!The addition of the
_setClientChainGatewayLogicinternal function is a good improvement:
- It encapsulates the logic for setting the client chain gateway, promoting modularity and reusability.
- The function includes validation checks for the provided parameters, ensuring that the gateway logic address is not zero and the initialization data is of sufficient length.
This modular approach enhances code organization and maintainability.
66-68: Verify the usage of the new constructor parameters in theinitializefunction.Ensure that
clientChainGatewayLogic_andclientChainInitializationData_are properly utilized in theinitializefunction to set up the client chain gateway.Run the following script to verify the usage of the new constructor parameters:
Verification successful
Parameters are correctly utilized in the
initializefunction.The parameters
clientChainGatewayLogic_andclientChainInitializationData_are used in theinitializefunction, specifically in the_setClientChainGatewayLogicfunction call, confirming their intended usage.
clientChainGatewayLogic_andclientChainInitializationData_are passed to_setClientChainGatewayLogic.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of `clientChainGatewayLogic_` and `clientChainInitializationData_` in the `initialize` function. # Test: Search for the usage of `clientChainGatewayLogic_` and `clientChainInitializationData_`. Expect: Usage in the `initialize` function. rg --type solidity -A 5 $'clientChainGatewayLogic_|clientChainInitializationData_'Length of output: 116
Script:
#!/bin/bash # Description: Verify the usage of `clientChainGatewayLogic_` and `clientChainInitializationData_` in the `initialize` function. # Test: Search for the usage of `clientChainGatewayLogic_` and `clientChainInitializationData_`. Expect: Usage in the `initialize` function. rg -A 5 'clientChainGatewayLogic_|clientChainInitializationData_'Length of output: 985
test/foundry/unit/ExocoreGateway.t.sol (5)
889-889: New state variablenativeFeeadded.The
nativeFeevariable stores the fee required for callingmarkBootstrap. This aligns with the PR objective of allowing retries by requiring the caller to provide the native fee for the transaction.
891-892: New custom errorNoPeeradded.The
NoPeererror is emitted whenmarkBootstrapis called with an unregistered chain ID. This improves error handling and aligns with the PR objective of ensuring that failures in themarkBootstrappedprocess do not disrupt the overall system functionality.
893-896:setUpfunction updated to initializenativeFee.The
setUpfunction now initializes thenativeFeeby quoting the fee required for callingmarkBootstrapwith theclientChainId. This setup aligns with the changes made to themarkBootstrapfunction.
903-903:test_Successfunction updated to passnativeFee.The
test_Successfunction now passes thenativeFeewhen callingmarkBootstrap. This aligns with the updatedmarkBootstrapfunction signature that requires the native fee to be provided.
906-909:test_Failfunction updated to expectNoPeererror.The
test_Failfunction now expects theNoPeererror to be emitted when callingmarkBootstrapwith an unregistered chain ID (clientChainId + 1). This test case verifies the correct error handling for invalid chain IDs.test/foundry/unit/Bootstrap.t.sol (10)
103-115: LGTM!The code changes are approved.
129-137: LGTM!The code changes are approved.
1012-1020: LGTM!The code changes are approved.
1043-1051: LGTM!The code changes are approved.
1072-1081: LGTM!The code changes are approved.
1102-1105: LGTM!The code changes are approved.
1125-1128: LGTM!The code changes are approved.
1148-1163: LGTM!The code changes are approved.
1165-1193: LGTM!The code changes are approved.
1195-1217: LGTM!The code changes are approved.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
docs/architecture.svgis excluded by!**/*.svg
Files selected for processing (1)
- test/mocks/ExocoreGatewayMock.sol (1 hunks)
Additional context used
Learnings (1)
test/mocks/ExocoreGatewayMock.sol (1)
Learnt from: adu-web3 PR: ExocoreNetwork/exocore-contracts#23 File: test/mocks/ExocoreGatewayMock.sol:0-0 Timestamp: 2024-06-17T07:43:43.986Z Learning: User adu-web3 suggests that the `chainToBootstrapped[clientChainId]` marking in `ExocoreGatewayMock.sol` has no significant effects beyond setting a state and that synchronization issues are currently not a concern. They are open to implementing a response check in the future if necessary.
Additional comments not posted (2)
test/mocks/ExocoreGatewayMock.sol (2)
110-114: LGTM!The code changes are approved. The function is correctly implemented and follows the best practices.
106-108: Verify the usage of thepayablekeyword.The function is marked as
payable, indicating that it can accept Ether. However, the received Ether is not used in the function.Please verify if the
payablekeyword is intended and if the received Ether is handled correctly in the broader context of the contract.To verify, run this script to search for the usage of
msg.valueoraddress(this).balance:
In the case where Bootstrap call first fails and then succeeds.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- src/core/Bootstrap.sol (4 hunks)
- src/storage/BootstrapStorage.sol (1 hunks)
- test/foundry/unit/Bootstrap.t.sol (12 hunks)
Files skipped from review as they are similar to previous changes (2)
- src/core/Bootstrap.sol
- src/storage/BootstrapStorage.sol
Additional context used
Learnings (1)
test/foundry/unit/Bootstrap.t.sol (1)
Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.
Additional comments not posted (14)
test/foundry/unit/Bootstrap.t.sol (14)
61-61: LGTM!The code changes are approved.
893-896: LGTM!The code changes are approved.
898-916: LGTM!The code changes are approved.
920-921: LGTM!The code changes are approved.
943-948: LGTM!The code changes are approved.
951-956: LGTM!The code changes are approved.
1020-1028: LGTM!The code changes are approved.
1051-1059: LGTM!The code changes are approved.
1080-1089: LGTM!The code changes are approved.
1110-1113: LGTM!The code changes are approved.
1133-1136: LGTM!The code changes are approved.
1156-1170: LGTM!The code changes are approved.
1173-1201: LGTM!The code changes are approved.
1203-1225: LGTM!The code changes are approved.
in this case, it means if someone sent a bootstrap request after the contract has been bootstrapped and upgraded, this request would revert because the exocore-contracts/src/core/BootstrapLzReceiver.sol Lines 25 to 42 in 021ea9d |
Extremely good catch. Added to the |
yeah, you are right. |
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- src/core/ClientChainGateway.sol (2 hunks)
- src/core/ClientGatewayLzReceiver.sol (1 hunks)
- test/foundry/unit/Bootstrap.t.sol (12 hunks)
Files skipped from review as they are similar to previous changes (1)
- test/foundry/unit/Bootstrap.t.sol
Additional context used
Learnings (1)
src/core/ClientChainGateway.sol (1)
Learnt from: MaxMustermann2 PR: ExocoreNetwork/exocore-contracts#16 File: test/foundry/Bootstrap.t.sol:156-156 Timestamp: 2024-06-03T13:57:54.251Z Learning: The `setClientChainGatewayLogic` method in `src/core/Bootstrap.sol` now includes checks to ensure the address is non-zero and the initialization data is at least 4 bytes long to include the function selector.
Additional comments not posted (3)
src/core/ClientChainGateway.sol (2)
74-75: LGTM!The code changes are approved. The
_whiteListFunctionSelectorsentry forAction.REQUEST_MARK_BOOTSTRAPis correctly updated to use theafterReceiveMarkBootstrapRequestfunction selector for processing bootstrap requests.
Line range hint
88-102: Verify the impact of not clearing the bootstrap-related function selector.The
_clearBootstrapDatafunction no longer clears the_whiteListFunctionSelectorsentry forAction.REQUEST_MARK_BOOTSTRAP. Ensure that this change does not have any unintended consequences on the bootstrap process.Run the following script to verify the impact:
src/core/ClientGatewayLzReceiver.sol (1)
330-336: LGTM!The new
afterReceiveMarkBootstrapRequestfunction is implemented correctly to handle the scenario where a mark-bootstrap response is received after the contract is already bootstrapped. The function silently ignores the call and emits aBootstrappedAlreadyevent to signal that the bootstrap process has already been completed. This implementation prevents nonce mismatches and system halts that could occur if the function were to fail.The
onlyCalledFromThisandwhenNotPausedmodifiers ensure that the function can only be called from within the contract and when the contract is not paused.The comments provide clear and concise documentation for the function's purpose and behavior.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- test/foundry/unit/Bootstrap.t.sol (12 hunks)
Files skipped from review as they are similar to previous changes (1)
- test/foundry/unit/Bootstrap.t.sol
|
@coderabbitai review |
Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- test/foundry/unit/Bootstrap.t.sol (11 hunks)
Files skipped from review as they are similar to previous changes (1)
- test/foundry/unit/Bootstrap.t.sol
markBootstrappedonBootstrapshould not fail. Fixes Mark bootstrap failures should not halt the system #89initializefunction of theBootstrapcontract must be provided with the address of theclientChainGatewayLogicand its initialization data.Summary by CodeRabbit
New Features
Bug Fixes
Tests