Skip to content
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

feat: unify version modifier for v2 #21508

Merged
merged 12 commits into from
Sep 6, 2024
Merged

feat: unify version modifier for v2 #21508

merged 12 commits into from
Sep 6, 2024

Conversation

randygrok
Copy link
Collaborator

@randygrok randygrok commented Sep 2, 2024

Description

Closes: #21418


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title, you can find examples of the prefixes below:
  • confirmed ! in the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • reviewed "Files changed" and left comments if necessary
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • updated the relevant documentation or specification, including comments for documenting Go code
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

Please see Pull Request Reviewer section in the contributing guide for more information on how to review a pull request.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

Summary by CodeRabbit

  • New Features

    • Enhanced application version management functionality added to the consensus module.
    • Improvements to gas limit handling and context structure in the BranchService.
    • Streamlined version retrieval process in the BaseApp.
    • New functionality added to manage application versioning in relation to consensus parameters.
    • Enhanced initialization process for testing with version modifiers.
  • Bug Fixes

    • Minor correction in documentation for clarity.
  • Tests

    • Enhanced test cases for BranchService to ensure accurate gas usage validation.
    • Added mock version modifier for improved testing flexibility.
  • Chores

    • Updated dependencies to improve testing capabilities and data handling features.

Copy link
Contributor

coderabbitai bot commented Sep 2, 2024

Walkthrough

Walkthrough

The changes involve updates across multiple files, primarily enhancing version management, refining gas limit handling, and improving testing capabilities. Key modifications include the introduction of a new versionModifier type in the consensus module, adjustments to gas limit calculations in the BranchService, and the integration of the require assertion library for testing. These updates aim to streamline functionality and enhance code clarity.

Changes

Files Change Summary
core/server/app.go Corrected comment documentation for VersionModifier interface.
runtime/v2/module.go Removed unused imports and the ProvideAppVersionModifier function to streamline code.
runtime/module.go Removed unused imports and the ProvideAppVersionModifier function to streamline code.
server/v2/stf/core_branch_service.go Modified gas limit calculation in ExecuteWithGasLimit and added new fields to the context in execute.
server/v2/stf/core_branch_service_test.go Added require package for assertions and enhanced gas usage validation in tests.
server/v2/stf/go.mod Updated dependencies to include new testing and data handling libraries.
x/consensus/depinject.go Introduced versionModifier type and methods for managing application versions, along with a provider function.
baseapp/baseapp.go Added versionModifier field to BaseApp and modified AppVersion method to use it.
baseapp/options.go Updated SetAppVersion to use versionModifier and added SetVersionModifier method.
simapp/app.go Enhanced NewSimApp to set the version modifier using consensus parameters.

Assessment against linked issues

Objective Addressed Explanation
Update app version in baseapp and server/v2 (#[21418])
Remove VersionModifier from core/server as it is baseapp specific (#[21418]) VersionModifier remains in core/server.
Ensure consistent version update between baseapp & server/v2 without x/consensus dependency (#[21418]) It is unclear if the changes maintain consistency.

Possibly related 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?

Share
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.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

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.

This comment has been minimized.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 5fb584a and fbb1d29.

Files ignored due to path filters (1)
  • server/v2/stf/go.sum is excluded by !**/*.sum
Files selected for processing (6)
  • core/server/app.go (1 hunks)
  • runtime/v2/module.go (3 hunks)
  • server/v2/stf/core_branch_service.go (2 hunks)
  • server/v2/stf/core_branch_service_test.go (3 hunks)
  • server/v2/stf/go.mod (1 hunks)
  • x/consensus/depinject.go (3 hunks)
Files skipped from review due to trivial changes (2)
  • core/server/app.go
  • runtime/v2/module.go
Additional context used
Path-based instructions (3)
server/v2/stf/core_branch_service.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

x/consensus/depinject.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

server/v2/stf/core_branch_service_test.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.


Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"

Additional comments not posted (12)
server/v2/stf/go.mod (4)

10-10: LGTM!

The addition of the testify dependency is approved. It's a widely used testing library in Go and will enhance the module's testing capabilities.


15-15: LGTM!

The addition of the indirect dependency on go-spew is approved. It's a useful package for debugging Go data structures and is likely required by one of the direct dependencies.


17-17: LGTM!

The addition of the indirect dependency on go-difflib is approved. It's a useful package for computing differences between Go structures and is likely required by one of the direct dependencies, such as testify.


19-19: LGTM!

The addition of the indirect dependency on yaml.v3 is approved. It's a useful package for handling YAML data in Go and is likely required by one of the direct dependencies.

server/v2/stf/core_branch_service.go (2)

44-44: LGTM!

The code change simplifies the logic for setting the gas limit by directly using the remaining gas value from the original gas meter. It does not introduce any correctness issues.


65-66: LGTM!

The addition of the msgRouter and queryRouter fields to the branchedCtx context enhances its capabilities for handling messages and queries. This change suggests an expansion of the service's ability to process tasks and does not introduce any correctness issues.

x/consensus/depinject.go (3)

4-8: LGTM!

The imports are correctly added and follow the Uber Golang style guide.


27-27: LGTM!

The registration of the ProvideAppVersionModifier function is correctly added and follows the Uber Golang style guide.


77-110: LGTM!

The versionModifier struct, its methods, and the ProvideAppVersionModifier function are correctly implemented and follow the Uber Golang style guide. The error handling in the SetAppVersion and AppVersion methods is also correctly implemented.

server/v2/stf/core_branch_service_test.go (3)

9-9: LGTM!

Adding the require package from the testify library is a good practice for writing more expressive and readable tests.


75-75: LGTM!

Capturing the remaining gas before executing the function is necessary for asserting the gas consumption later. The variable name originalGas clearly conveys the purpose of the variable.


86-86: LGTM!

The assertion ensures that the gas used during the execution matches the difference between the original gas and the remaining gas. This is important for validating the gas accounting when the state reverts due to an error.

@julienrbrt julienrbrt added the backport/v0.52.x PR scheduled for inclusion in the v0.52's next stable release label Sep 2, 2024
@julienrbrt
Copy link
Member

Adding the backport label as there are changes in a module.

@julienrbrt julienrbrt changed the title fix: unify version modifier for v2 feat: unify version modifier for v2 Sep 2, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (1)
server/v2/stf/core_branch_service.go (1)

65-66: Provide more information about the new context fields.

The msgRouter and queryRouter fields have been added to the context structure in the execute method. These fields suggest an enhancement in the context's capabilities, potentially enabling more complex interactions within the service.

To improve code clarity and maintainability, consider adding comments or documentation explaining the purpose and usage of these new fields. This will help future developers understand their role and how they contribute to the overall functionality of the BranchService.

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 5fb584a and fbb1d29.

Files ignored due to path filters (1)
  • server/v2/stf/go.sum is excluded by !**/*.sum
Files selected for processing (6)
  • core/server/app.go (1 hunks)
  • runtime/v2/module.go (3 hunks)
  • server/v2/stf/core_branch_service.go (2 hunks)
  • server/v2/stf/core_branch_service_test.go (3 hunks)
  • server/v2/stf/go.mod (1 hunks)
  • x/consensus/depinject.go (3 hunks)
Files skipped from review due to trivial changes (2)
  • core/server/app.go
  • runtime/v2/module.go
Additional context used
Path-based instructions (3)
server/v2/stf/core_branch_service.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

x/consensus/depinject.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

server/v2/stf/core_branch_service_test.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.


Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"

Additional comments not posted (12)
server/v2/stf/go.mod (4)

10-10: LGTM!

Adding the testify testing framework is a good practice to improve the quality of the codebase. The version specified is the latest stable version at the time of this review.


15-15: LGTM!

The go-spew library is likely a transitive dependency of testify. The version specified is the latest stable version at the time of this review. Marking the dependency as indirect is correct since it is not directly used by the module.


17-17: LGTM!

The go-difflib library is likely a transitive dependency of testify. The version specified is the latest stable version at the time of this review. Marking the dependency as indirect is correct since it is not directly used by the module.


19-19: LGTM!

The yaml.v3 library is likely a transitive dependency of testify. The version specified is the latest stable version at the time of this review. Marking the dependency as indirect is correct since it is not directly used by the module.

server/v2/stf/core_branch_service.go (1)

44-44: Verify the impact of the gas limit calculation change.

The gas limit calculation has been simplified to directly use the remaining gas value. This change may affect how gas limits are handled during execution.

Ensure that this change does not introduce any unintended side effects or break existing functionality. Thoroughly test the gas limit handling in various scenarios to validate the correctness of the new approach.

To verify the impact, run the following script:

Verification successful

Verify the impact of the gas limit calculation change through existing tests.

The ExecuteWithGasLimit method is used in various parts of the codebase, and there are multiple test cases that cover different scenarios related to gas limits. These tests should help ensure that the change in gas limit calculation does not introduce any unintended side effects. Please verify the test results to confirm the correctness of the new approach.

  • Test files: server/v2/stf/core_branch_service_test.go, runtime/branch_test.go
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the impact of the gas limit calculation change.

# Test 1: Search for the `ExecuteWithGasLimit` method usage. 
# Expect: Identify the code paths that invoke this method.
rg --type go -A 5 $'ExecuteWithGasLimit'

# Test 2: Search for test cases related to gas limit handling.
# Expect: Identify existing test cases that cover gas limit scenarios.
rg --type go -A 5 $'ExecuteWithGasLimit' $(fd _test.go$)

Length of output: 34917

x/consensus/depinject.go (4)

77-110: LGTM!

The code segment follows the Uber Go Style Guide and is well-structured. The versionModifier type and its methods provide a clean way to manage the application version. The ProvideAppVersionModifier function acts as a dependency injection provider, which is a good practice.


82-97: LGTM!

The SetAppVersion method is implemented correctly and handles errors appropriately. It follows the Uber Go Style Guide.


99-106: LGTM!

The AppVersion method is implemented correctly and handles errors appropriately. It follows the Uber Go Style Guide.


27-27: LGTM!

The registration of the ProvideAppVersionModifier function as a dependency injection provider for the consensus module is done correctly and follows the established pattern in the file.

server/v2/stf/core_branch_service_test.go (3)

9-9: LGTM!

The import statement for the require package is approved. It is a common assertion library used in Go testing and facilitates more expressive assertions within the test cases.


75-75: LGTM!

The introduction of the originalGas variable is approved. It is crucial for validating the gas consumption during the execution of the ExecuteWithGasLimit method.


86-86: LGTM!

The assertion is approved. It enhances the test's robustness by ensuring that the gas accounting is accurate, thereby improving the reliability of the test outcomes.

The previous comment by tac0turtle is no longer applicable as the assertion is now using the require package.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between fbb1d29 and eeb0d7a.

Files selected for processing (1)
  • server/v2/stf/core_branch_service_test.go (3 hunks)
Files skipped from review as they are similar to previous changes (1)
  • server/v2/stf/core_branch_service_test.go

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between eeb0d7a and 09bd7b0.

Files selected for processing (4)
  • baseapp/baseapp.go (3 hunks)
  • baseapp/options.go (3 hunks)
  • runtime/module.go (3 hunks)
  • simapp/app.go (1 hunks)
Additional context used
Path-based instructions (4)
runtime/module.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

baseapp/options.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

simapp/app.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

baseapp/baseapp.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

Additional comments not posted (8)
runtime/module.go (2)

Line range hint 4-4: Approved import removal.

The removal of the server package import is consistent with the removal of the ProvideAppVersionModifier function that returned a server.VersionModifier. This change suggests that the module no longer depends on server-related functionalities.


Line range hint 81-83: Verify the impact of the ProvideAppVersionModifier function removal on the application lifecycle.

The removal of the ProvideAppVersionModifier function indicates a possible refactoring or a decision to manage application versioning differently. This change may affect how versioning is integrated into the application lifecycle.

Please provide more context on how the application versioning will be handled after this change. Also, ensure that the removal of this function does not break any existing functionality.

baseapp/options.go (2)

329-335: LGTM!

The addition of the SetVersionModifier method is a good design choice. It allows for greater flexibility in managing versioning within the application. The check to prevent calling the function on a sealed BaseApp is also a good defensive programming practice.


163-167: Verify the usage of SetAppVersion in the codebase.

The implementation logic of SetAppVersion has been significantly modified. It now uses a versionModifier instead of a paramStore to set the app version.

Please run the following script to verify the usage of SetAppVersion across the codebase:

If the verification passes and no issues are found, the changes can be approved.

Verification successful

The usage of SetAppVersion is consistent and correct.

The SetAppVersion function is used appropriately across the codebase with the versionModifier, and its functionality is verified through tests. The change from paramStore to versionModifier is well-integrated. No issues were found with the current implementation.

  • Files where SetAppVersion is used:
    • x/upgrade/keeper/keeper.go
    • x/upgrade/keeper/migrations.go
    • x/consensus/depinject.go
    • core/server/app.go
    • baseapp/abci_test.go
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `SetAppVersion` provide a `versionModifier`.

# Test: Search for usage of `SetAppVersion`. Expect: All calls provide a `versionModifier`.
rg --type go -A 5 $'SetAppVersion'

Length of output: 2303

simapp/app.go (1)

299-300: Verify the usage of the version modifier in the codebase.

Ensure that the introduction of the version modifier does not lead to any inconsistencies or unexpected behavior in the application.

To verify the correct usage of the version modifier, run the following script:

baseapp/baseapp.go (3)

5-5: LGTM!

The code change is approved.


259-263: LGTM!

The code changes are approved. The changes to the AppVersion method are consistent with the changes to the BaseApp struct and improve the error handling.


93-93: Verify the usage of BaseApp in the codebase.

Ensure that all usages of BaseApp are updated to handle the change in the type of versionModifier field.

Run the following script to verify the usage of BaseApp:

Verification successful

Verification Successful: BaseApp Usage Updated

The versionModifier field in the BaseApp struct has been updated to use server.VersionModifier, and this change is reflected correctly across the codebase. No instances of the old sdk.VersionModifier type were found in the usage of BaseApp.

  • The change is confirmed in x/upgrade/keeper/keeper.go where server.VersionModifier is used.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all usages of `BaseApp` are updated to handle the change in the type of `versionModifier` field.

# Test: Search for the usage of `BaseApp`. Expect: No usages of `BaseApp.versionModifier` with the old type `sdk.VersionModifier`.
rg --type go -A 5 $'BaseApp'

Length of output: 199605

Copy link
Member

@julienrbrt julienrbrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing baseapp options for runtime v1 in consensus, but the rest lgtm!

simapp/app.go Show resolved Hide resolved
baseapp/options.go Show resolved Hide resolved
@@ -72,3 +74,37 @@ func ProvideModule(in ModuleInputs) ModuleOutputs {
BaseAppOption: baseappOpt,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 68, we should return a baseapp option that sets the version modifier too:

	baseappOpt := func(app *baseapp.BaseApp) {
	      app.SetParamStore(k.ParamsStore)
+             app.SetVersionModifier(versionModifier{Keeper: k})
	}

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 09bd7b0 and fc64ac8.

Files selected for processing (1)
  • simapp/app.go (1 hunks)
Additional context used
Path-based instructions (1)
simapp/app.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

Additional comments not posted (1)
simapp/app.go (1)

299-300: Setting the version modifier for the application.

The changes introduce a new functionality to set a version modifier for the application based on the consensus parameters. This enhances the application's ability to manage versioning in relation to its consensus parameters.

Please verify that the version modifier is correctly set and used throughout the application. Ensure that the application behaves as expected in different versions or states.

Skipping the comment to add a note in simapp/CHANGELOG.md as it's still valid from the previous review.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between fc64ac8 and 94ec53c.

Files selected for processing (3)
  • baseapp/options.go (3 hunks)
  • simapp/CHANGELOG.md (1 hunks)
  • x/consensus/depinject.go (4 hunks)
Files skipped from review as they are similar to previous changes (1)
  • x/consensus/depinject.go
Additional context used
Path-based instructions (2)
simapp/CHANGELOG.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

baseapp/options.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

Additional comments not posted (4)
simapp/CHANGELOG.md (1)

49-49: LGTM!

The changelog entry for pull request #21508 is well-written and informative. It clearly describes the introduction of the VersionModifier interface for updating the application state version in app.go, highlighting the benefits of improved flexibility and maintainability.

baseapp/options.go (3)

163-167: LGTM!

The changes to the SetAppVersion method look good. The use of a versionModifier simplifies the version setting logic and the error handling ensures that the versionModifier is set before setting the version.


330-330: The existing comment by julienrbrt is still valid:

let's add a go doc

Please add a godoc comment describing the purpose of the SetVersionModifier method.


331-336: LGTM!

The SetVersionModifier method looks good. The check to prevent modifying the versionModifier after the BaseApp is sealed is a good practice and the implementation follows the pattern of other setter methods in the file.

Copy link
Member

@julienrbrt julienrbrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some tests are failing but lgtm!

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 94ec53c and d3ed27d.

Files selected for processing (4)
  • baseapp/baseapp_test.go (1 hunks)
  • baseapp/utils_test.go (2 hunks)
  • runtime/module.go (3 hunks)
  • runtime/v2/module.go (3 hunks)
Files skipped from review due to trivial changes (1)
  • runtime/v2/module.go
Files skipped from review as they are similar to previous changes (1)
  • runtime/module.go
Additional context used
Path-based instructions (2)
baseapp/utils_test.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.


Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"

baseapp/baseapp_test.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.


Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"

Additional comments not posted (2)
baseapp/utils_test.go (1)

450-465: Review of newMockedVersionModifier and mockedVersionModifier

The new function newMockedVersionModifier and the struct mockedVersionModifier are well-implemented for the purpose of version management in tests. Here are specific observations and suggestions:

  1. Functionality: The newMockedVersionModifier function correctly initializes an instance of mockedVersionModifier with a given starting version. This is crucial for testing scenarios where version state needs to be manipulated.

  2. Method Implementation:

    • SetAppVersion: This method correctly sets the version to a new value. It's straightforward and effective for changing the version during tests.
    • AppVersion: This method retrieves the current version. It's simple and serves its purpose well.
  3. Error Handling: Both methods SetAppVersion and AppVersion do not currently handle any specific errors related to the version setting or getting. Since this is a mock implementation used for testing, this is acceptable. However, if this pattern is used in production code, error handling should be considered.

  4. Testing: The implementation is part of the testing suite, which is good as it isolates version management testing from production code. Ensure that tests using these methods are robust enough to cover various scenarios of version changes.

  5. Documentation: Consider adding inline comments or documentation to these methods to explain their usage, especially since they are part of a testing framework. This can help other developers understand their purpose and usage context quickly.

Overall, the additions are well-suited for their intended testing purposes and follow good coding practices.

baseapp/baseapp_test.go (1)

84-84: Review of the addition of SetVersionModifier in NewBaseAppSuite.

The addition of app.SetVersionModifier(newMockedVersionModifier(0)) at line 84 is a crucial change that aligns with the PR's objective to unify version handling across the SDK. This change ensures that the version modifier is set during the initialization of the BaseAppSuite, which is likely used to simulate different versioning scenarios during testing.

  • Correctness: The method call is syntactically correct and matches the expected usage pattern in Go.
  • Contextual Fit: This change fits well within the context of the PR, which aims to manage version consistency.
  • Testing: Given that this is a test suite file, the change directly impacts how tests might behave with version modifications. It's essential to ensure that other tests within this suite or dependent tests are aware of this versioning behavior to avoid unexpected outcomes.

Recommendation: Ensure that all tests using BaseAppSuite are reviewed to accommodate this new versioning behavior, especially those that might rely on version-specific logic. It might also be beneficial to add specific tests that verify the behavior of the newMockedVersionModifier function to ensure it behaves as expected across different scenarios.

@julienrbrt julienrbrt added this pull request to the merge queue Sep 6, 2024
Merged via the queue into main with commit dce0365 Sep 6, 2024
74 of 76 checks passed
@julienrbrt julienrbrt deleted the randy/version-modifier branch September 6, 2024 16:00
mergify bot pushed a commit that referenced this pull request Sep 6, 2024
(cherry picked from commit dce0365)

# Conflicts:
#	baseapp/utils_test.go
#	core/server/app.go
#	runtime/v2/module.go
#	server/v2/stf/core_branch_service.go
#	server/v2/stf/core_branch_service_test.go
@julienrbrt julienrbrt mentioned this pull request Sep 6, 2024
12 tasks
julienrbrt added a commit that referenced this pull request Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/v0.52.x PR scheduled for inclusion in the v0.52's next stable release C:server/v2 stf C:server/v2 Issues related to server/v2 C:x/consensus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bump app version after upgrade in v2 path
4 participants