fix(contracts-communication): default settings for Guard service

[ChiTimesChi]

Description
Updated to match the following spec:

• App could choose from three possible Guard configurations:
  • No guard (disabled). This is the default option.
  • Use Client’s default Guard. This is the opt-in option, where the app needs to provide its own optimistic period as well.
  • Use App’s own custom Guard. Similar to the above, we can delegate the responsibility of defining the optimistic period to the app itself.
• Optimistic period is ignored if the app doesn’t use any guards. At this point, as soon as there are enough confirmations, the message could be executed.
• Optimistic period (as defined by the app) is enforced should the app opt into using a Guard service.

Note: the optimistic period check is strict (more than X seconds need to pass), so confirming the entry and executing in the same block is not possible even for the optimistic period of zero.

Summary by CodeRabbit

• New Features

  • Introduced a new configuration setting for guard functionality across multiple contracts to enhance security and operational flexibility.
  • Added new test functions to validate application configuration and modules effectively.

• Improvements

  • Updated the logic for calculating the optimistic period in contract operations, ensuring more accurate and secure transaction processing.
  • Enhanced the assignment process of source chain identifiers to streamline interchain communication.

• Bug Fixes

  • Corrected guard configuration settings in various contracts to align with updated security protocols.
  • Fixed inconsistencies in timestamp comparisons in test contracts to improve reliability.

• Refactor

  • Simplified import statements and removed redundant code across several test suites to improve maintainability and performance.
  • Consolidated constants and utility functions to reduce redundancy and enhance clarity in integration tests.

• Documentation

  • Updated import paths and configuration settings in documentation to reflect the latest changes and ensure ease of use.

[coderabbitai]

Walkthrough

The updates across various smart contracts and test files focus on refining guard configurations and response handling mechanisms. Changes include adjustments to optimistic period calculations, import modifications, and enhancements in test setups to align with the updated logic in the main contracts.

Changes

File Path	Change Summary
.../contracts/InterchainClientV1.sol, .../contracts/apps/ICAppV1.sol	Updated optimistic period calculations and guard configurations.
.../contracts/apps/examples/PingPongApp.sol, .../contracts/libs/InterchainEntry.sol	Added new functionalities and refactored existing logic for clarity and efficiency.
.../test/InterchainClientV1.Dst.t.sol, .../test/InterchainDB.Src.t.sol, .../test/apps/ICAppV1.Messaging.t.sol, .../test/apps/InterchainAppV1.Management.t.sol, .../test/integration/ICSetup.t.sol, .../test/integration/PingPong.t.sol, .../test/integration/legacy/LegacyPingPong.Dst.t.sol, .../test/integration/legacy/LegacyPingPong.t.sol	Enhanced testing protocols to reflect changes in the main contracts and ensure robustness.

🐰✨
Oh hooray! Oh joy! What a splendid day,
For code has changed in a wonderful way.
Guards are set, and tests are met,
In the blockchain's weave, the best update yet!
So hop along, let's sing this song,
As our code hops right, never wrong! 🎶🌟
🐰💻

---

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?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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 as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 40.78753%. Comparing base (be4351b) to head (3ba391e).
Report is 3 commits behind head on master.

Additional details and impacted files

@@                 Coverage Diff                 @@
##              master       #2605         +/-   ##
===================================================
+ Coverage   40.77234%   40.78753%   +0.01518%     
===================================================
  Files            224         224                 
  Lines          15589       15593          +4     
  Branches         261         261                 
===================================================
+ Hits            6356        6360          +4     
  Misses          8460        8460                 
  Partials         773         773                 

Flag	Coverage Δ
packages	90.47619% <ø> (ø)
solidity	57.36138% <100.00000%> (+0.16367%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cloudflare-workers-and-pages]

Deploying sanguine-fe with    Cloudflare Pages

Latest commit:	3ba391e
Status:	✅  Deploy successful!
Preview URL:	https://836c3234.sanguine-fe.pages.dev
Branch Preview URL:	https://fix-interchain-guard-default.sanguine-fe.pages.dev

View logs

[coderabbitai]

Actionable comments posted: 0

Review Details

Configuration used: .coderabbit.yaml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 84da80d and 3ba391e.

Files selected for processing (13)

• packages/contracts-communication/contracts/InterchainClientV1.sol (1 hunks)
• packages/contracts-communication/contracts/apps/ICAppV1.sol (3 hunks)
• packages/contracts-communication/contracts/apps/examples/PingPongApp.sol (2 hunks)
• packages/contracts-communication/contracts/libs/InterchainEntry.sol (2 hunks)
• packages/contracts-communication/test/InterchainClientV1.Dst.t.sol (1 hunks)
• packages/contracts-communication/test/InterchainDB.Src.t.sol (1 hunks)
• packages/contracts-communication/test/apps/ICAppV1.Messaging.t.sol (1 hunks)
• packages/contracts-communication/test/apps/InterchainAppV1.Management.t.sol (3 hunks)
• packages/contracts-communication/test/apps/InterchainAppV1.Messaging.t.sol (1 hunks)
• packages/contracts-communication/test/integration/ICSetup.t.sol (4 hunks)
• packages/contracts-communication/test/integration/PingPong.t.sol (3 hunks)
• packages/contracts-communication/test/integration/legacy/LegacyPingPong.Dst.t.sol (4 hunks)
• packages/contracts-communication/test/integration/legacy/LegacyPingPong.t.sol (3 hunks)

Files skipped from review due to trivial changes (1)

• packages/contracts-communication/test/InterchainDB.Src.t.sol

Additional comments not posted (25)

packages/contracts-communication/test/apps/ICAppV1.Messaging.t.sol (4)

4-4: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The verification process has confirmed that the file AppConfig.sol exists at the path packages/contracts-communication/contracts/libs/AppConfig.sol. This matches the import path specified in the file ICAppV1.Messaging.t.sol, which is ../../contracts/libs/AppConfig.sol. Given the relative path from the test directory to the contracts directory, this path is correct and accessible.

Therefore, the import statement in the ICAppV1.Messaging.t.sol file is verified to be correct.

• File: packages/contracts-communication/test/apps/ICAppV1.Messaging.t.sol
  • Import path for AppConfig.sol is correct and accessible.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for AppConfig.sol in ICAppV1.Messaging.t.sol.

# Test: Search for the file AppConfig.sol. Expect: At least one occurrence.
fd --type file 'AppConfig.sol'

Length of output: 92

---

5-5: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The verification process has confirmed the existence of the file InterchainAppV1.Messaging.t.sol within the repository, specifically located at packages/contracts-communication/test/apps/InterchainAppV1.Messaging.t.sol. This confirms that the import path mentioned in the review comment is correct and the file is accessible within the codebase.

Since the file exists and is located where expected, the import statement in ICAppV1.Messaging.t.sol referring to InterchainAppV1.Messaging.t.sol is correct and accessible.

• File InterchainAppV1.Messaging.t.sol is located at packages/contracts-communication/test/apps/InterchainAppV1.Messaging.t.sol.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for InterchainAppV1.Messaging.t.sol in ICAppV1.Messaging.t.sol.

# Test: Search for the file InterchainAppV1.Messaging.t.sol. Expect: At least one occurrence.
fd --type file 'InterchainAppV1.Messaging.t.sol'

Length of output: 123

---

22-29: The test function test_freshAppConfig correctly checks the initial state of the app configuration.

---

31-34: The test function test_freshAppModules correctly checks the initial state of the modules array.

packages/contracts-communication/test/integration/PingPong.t.sol (3)

6-6: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The verification process has confirmed that the file ICIntegration.t.sol exists within the repository at the path packages/contracts-communication/test/integration/ICIntegration.t.sol. This matches the import path specified in the PingPong.t.sol file, indicating that the path in the import statement is correct and accessible.

Therefore, the import statement at line 6 in PingPong.t.sol is verified to be correct.

• File path verified: packages/contracts-communication/test/integration/ICIntegration.t.sol

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for ICIntegration.t.sol in PingPong.t.sol.

# Test: Search for the file ICIntegration.t.sol. Expect: At least one occurrence.
fd --type file 'ICIntegration.t.sol'

Length of output: 106

---

16-16: The constant APP_OPTIMISTIC_PERIOD is correctly set to 10 minutes, aligning with the new specifications.

---

82-84: The function getAppOptimisticPeriod correctly returns the optimistic period set in the constant APP_OPTIMISTIC_PERIOD.

packages/contracts-communication/contracts/libs/InterchainEntry.sol (2)

1-1: Ensure the path in the import statement is correct and accessible.

---

40-41: The function constructLocalEntry correctly constructs an InterchainEntry struct using the current chain ID.

packages/contracts-communication/contracts/apps/examples/PingPongApp.sol (2)

6-6: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The import path in PingPongApp.sol for AppConfig.sol is correctly specified and accessible. The file structure and relative path align correctly, confirming that the import statement is accurate.

• File: packages/contracts-communication/contracts/apps/examples/PingPongApp.sol
• Import Path: ../../libs/AppConfig.sol resolves to packages/contracts-communication/contracts/libs/AppConfig.sol

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for AppConfig.sol in PingPongApp.sol.

# Test: Search for the file AppConfig.sol. Expect: At least one occurrence.
fd --type file 'AppConfig.sol'

Length of output: 92

---

96-98: The function _getGuardConfig correctly returns the default guard configuration, aligning with the new specifications.

packages/contracts-communication/test/integration/legacy/LegacyPingPong.t.sol (3)

11-11: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The import path in the file LegacyPingPong.t.sol is correctly set and points to an existing file in the repository. The relative path used in the import statement accurately navigates from the directory of LegacyPingPong.t.sol to ICIntegration.t.sol.

• File Path: packages/contracts-communication/test/integration/ICIntegration.t.sol

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for ICIntegration.t.sol in LegacyPingPong.t.sol.

# Test: Search for the file ICIntegration.t.sol. Expect: At least one occurrence.
fd --type file 'ICIntegration.t.sol'

Length of output: 106

---

29-29: The constant APP_OPTIMISTIC_PERIOD is correctly set to 0 for legacy scenarios, aligning with the new specifications.

---

160-162: The function getAppOptimisticPeriod correctly returns the optimistic period set in the constant APP_OPTIMISTIC_PERIOD for legacy scenarios.

packages/contracts-communication/test/integration/ICSetup.t.sol (2)

Line range hint 1-1: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The import path for InterchainClientV1.sol in ICSetup.t.sol is correctly set and points to an existing file in the repository. The relative path used in the import statement accurately locates the file from the position of ICSetup.t.sol.

• File: packages/contracts-communication/test/integration/ICSetup.t.sol
• Import Statement: import {InterchainClientV1} from "../../contracts/InterchainClientV1.sol";
• Target File Path: packages/contracts-communication/contracts/InterchainClientV1.sol

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for InterchainClientV1.sol in ICSetup.t.sol.

# Test: Search for the file InterchainClientV1.sol. Expect: At least one occurrence.
fd --type file 'InterchainClientV1.sol'

Length of output: 183

---

---

Script:

#!/bin/bash
# Description: Extract the import statement from ICSetup.t.sol to verify the correct file reference.

# Test: Display the import statements from ICSetup.t.sol. Expect: Specific import statement referencing InterchainClientV1.sol.
rg '^import' packages/contracts-communication/test/integration/ICSetup.t.sol

Length of output: 936

---

131-131: The function setAppConfigV1 correctly sets the app configuration, including the optimistic period.

packages/contracts-communication/test/integration/legacy/LegacyPingPong.Dst.t.sol (2)

Line range hint 1-1: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The import path for IInterchainClientV1.sol in the file LegacyPingPong.Dst.t.sol is correct and accessible as verified by the presence of the file in the expected directory.

• Location: packages/contracts-communication/contracts/interfaces/IInterchainClientV1.sol

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for IInterchainClientV1.sol in LegacyPingPong.Dst.t.sol.

# Test: Search for the file IInterchainClientV1.sol. Expect: At least one occurrence.
fd --type file 'IInterchainClientV1.sol'

Length of output: 118

---

180-183: The function test_interchainExecute_state_db_guardMarked correctly tests the state of the database when the guard is marked.

packages/contracts-communication/contracts/apps/ICAppV1.sol (2)

8-8: Ensure the path in the import statement is correct and accessible.

Verification successful

---

The verification process has confirmed that the file AppConfig.sol exists at the path packages/contracts-communication/contracts/libs/AppConfig.sol. This matches the import statement in the ICAppV1.sol file, which imports from "../libs/AppConfig.sol". Given that ICAppV1.sol is located under packages/contracts-communication/contracts/apps/, the relative path used in the import statement correctly points to the AppConfig.sol file in the libs directory.

Therefore, the path in the import statement is correct and accessible.

• File: packages/contracts-communication/contracts/apps/ICAppV1.sol
  • Line 8: Import statement is correct and the file AppConfig.sol is accessible at the specified path.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the import path for AppConfig.sol in ICAppV1.sol.

# Test: Search for the file AppConfig.sol. Expect: At least one occurrence.
fd --type file 'AppConfig.sol'

Length of output: 92

---

258-258: The function _getGuardConfig correctly returns the disabled guard configuration, aligning with the new specifications.

packages/contracts-communication/test/apps/InterchainAppV1.Messaging.t.sol (1)

131-131: Correct implementation of default guard settings in test configuration.

packages/contracts-communication/test/apps/InterchainAppV1.Management.t.sol (2)

401-409: Proper testing of app configuration with zero optimistic period when not previously set.

---

423-433: Effective testing of app configuration re-setting with zero optimistic period.

packages/contracts-communication/contracts/InterchainClientV1.sol (1)

432-436: Ensure correct handling of optimisticPeriod based on Guard configuration.

The logic to determine the optimisticPeriod based on whether a Guard is configured appears correct. This change aligns with the PR's objective to enforce the optimistic period strictly, even if set to zero.

packages/contracts-communication/test/InterchainClientV1.Dst.t.sol (1)

371-377: Verify correct handling of timestamps based on Guard configuration in tests.

The logic to determine the last accepted timestamp based on whether the Guard is disabled or not is correctly implemented in the test scenarios. This ensures that the tests accurately reflect the behavior of the main contract when different Guard configurations are used.