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

[CLOB-930, CORE-29] Extend the e2e test framework to start the cosmos app using cmd. #703

Merged
merged 2 commits into from
Oct 27, 2023

Conversation

lcwik
Copy link
Contributor

@lcwik lcwik commented Oct 25, 2023

Changelist

Extend the e2e test framework to start the cosmos app using cmd.

This works towards enabling and passing in flags for flag based testing. This also works towards enabling daemons on e2e app start-up once the daemons can be cleaned up. This relies on dydxprotocol/cosmos-sdk#29

Test Plan

Existing tests updated and pass.

Author/Reviewer Checklist

  • If this PR has changes that result in a different app state given the same prior state and transaction list, manually add the state-breaking label.
  • If this PR isn't state-breaking but has changes that modify behavior in PrepareProposal or ProcessProposal, manually add the label proposal-breaking.
  • If this PR is one of many that implement a specific feature, manually label them all feature:[feature-name].
  • If you wish to for mergify-bot to automatically create a PR to backport your change to a release branch, manually add the label backport/[branch-name].
  • Manually add any of the following labels: refactor, chore, bug.

@linear
Copy link

linear bot commented Oct 25, 2023

CLOB-930 Better testing framework for non-determinism, orderbook discrepancies, etc.

CORE-29 Gracefully shutdown daemons

Currently the liquidations daemon and prices daemon do not gracefully shutdown when a validator is stopped. This is an issue in the integration tests because when we shutdown the in-process validators, this can cause the daemon goroutines to panic and the test can fail.

However, not panicing is a security risk because it's possible that the validator is running while the daemon (liquidations or prices) is not running. The application assumes that the daemons are always running, and this assumption could lead to subaccounts not getting liquidated / prices not being updated.

As a longer term solution, we should do the following:

  • To fix the tests, we should gracefully stop the daemons when the validator stops running.
  • To fix the security risk, we should determine what failures in the daemon are intermittent and retry them. For persistent failures, we should stop the daemon and the application together.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 25, 2023

Walkthrough

The changes primarily focus on improving the initialization and setup of the application for testing, enhancing type safety, and allowing customization of server and app configurations through interceptors. Additionally, the changes also address fee handling in transaction-related tests and remove unnecessary dependencies.

Changes

File(s) Summary
protocol/app/ante/gas_test.go Simplified code by removing unused imports and unnecessary dependencies.
protocol/app/app_test.go Replaced dydxApp object creation with tApp object using a test app builder.
protocol/app/prepare/full_node_prepare_proposal_test.go Improved test setup by initializing the test application and configuring metrics properly.
protocol/cmd/dydxprotocold/cmd/config.go Enhanced type safety by changing the return type of initAppConfig function to a specific struct pointer.
protocol/cmd/dydxprotocold/cmd/root.go Allowed customization of server and app configurations through the use of interceptors.
protocol/testutil/app/app.go Improved the initialization and setup of the application for testing.
protocol/x/clob/e2e/order_removal_test.go Added FeeAmt field to MustMakeCheckTxOptions struct in two test functions.
protocol/x/sending/app_test.go Addressed fee handling in transaction-related tests.

Tips

Chat with CodeRabbit Bot (@coderabbitai)

  • If you reply to a review comment from CodeRabbit, the bot will automatically respond.
  • To engage with CodeRabbit bot directly around the specific lines of code in the PR, mention @coderabbitai in your review comment
  • Note: Review comments are made on code diffs or files, not on the PR overview.
  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

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 help to get help.

Note: For conversation with the bot, please use the review comments on code diffs or files.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • 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/coderabbit-overrides.json

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.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 71529ce and f2150de.
Files ignored due to filter (2)
  • protocol/go.mod
  • protocol/go.sum
Files selected for processing (8)
  • protocol/app/ante/gas_test.go (2 hunks)
  • protocol/app/app_test.go (1 hunks)
  • protocol/app/prepare/full_node_prepare_proposal_test.go (1 hunks)
  • protocol/cmd/dydxprotocold/cmd/config.go (2 hunks)
  • protocol/cmd/dydxprotocold/cmd/root.go (5 hunks)
  • protocol/testutil/app/app.go (5 hunks)
  • protocol/x/clob/e2e/order_removal_test.go (2 hunks)
  • protocol/x/sending/app_test.go (5 hunks)
Files skipped from review due to trivial changes (5)
  • protocol/app/ante/gas_test.go
  • protocol/app/app_test.go
  • protocol/app/prepare/full_node_prepare_proposal_test.go
  • protocol/x/clob/e2e/order_removal_test.go
  • protocol/x/sending/app_test.go
Additional comments: 14
protocol/cmd/dydxprotocold/cmd/config.go (2)
  • 34-34: The return type of the initAppConfig function has been changed from interface{} to *DydxAppConfig. This is a good change as it improves type safety and makes the code easier to understand. However, please ensure that all calls to this function throughout the codebase have been updated to handle the new return type.

  • 71-71: The appConfig is now returned as a pointer. This is a good practice as it can help to reduce memory usage and improve performance by avoiding unnecessary copying of the struct. However, please ensure that the returned pointer is always checked for nil before being dereferenced elsewhere in the code to avoid potential runtime panics.

protocol/cmd/dydxprotocold/cmd/root.go (6)
  • 53-68: The NewRootCmd function has been updated to call NewRootCmdWithInterceptors with default interceptors that do not modify the input. This change allows for customization of the server context, app configuration, and app instance in tests or other scenarios where customization is needed. However, it's important to ensure that these interceptors are used responsibly to avoid unintended side effects.

  • 110-110: The appConfigInterceptor function is now used to potentially modify the app configuration. This change allows for customization of the app configuration in tests or other scenarios where customization is needed. However, it's important to ensure that this interceptor is used responsibly to avoid unintended side effects.

  • 122-122: The serverCtxInterceptor function is now used to potentially modify the server context. This change allows for customization of the server context in tests or other scenarios where customization is needed. However, it's important to ensure that this interceptor is used responsibly to avoid unintended side effects.

  • 129-140: The initRootCmd function now accepts an appInterceptor argument. This change allows for customization of the app instance in tests or other scenarios where customization is needed. However, it's important to ensure that this interceptor is used responsibly to avoid unintended side effects.

  • 163-165: The appInterceptor function is now used to potentially modify the app instance. This change allows for customization of the app instance in tests or other scenarios where customization is needed. However, it's important to ensure that this interceptor is used responsibly to avoid unintended side effects.

  • 256-256: The return type of the newApp method has been changed from servertypes.Application to *dydxapp.App. This change improves type safety by returning a more specific type. However, it's important to ensure that all calls to this method throughout the codebase have been updated to handle the new return type.

protocol/testutil/app/app.go (6)
  • 5-19: The import of tmcfg "github.com/cometbft/cometbft/config" and tmcli "github.com/cometbft/cometbft/libs/cli" are new and seem to be used for setting up the root command and its execution context. Ensure that these packages are compatible with the rest of the codebase and that they are maintained and secure.

  • 63-85: The addition of alicePrivValidatorKeyJson and aliceNodeKeyJson constants is new. These constants seem to be used for setting up the validator's home directory. Ensure that these keys are not sensitive information and are safe to be hardcoded in the codebase.

  • 295-300: The baseAppOptions field has been removed from the TestAppBuilder struct. Ensure that this field is not used elsewhere in the codebase, as its removal could cause issues.

  • 309-316: The WithAppOptions function no longer accepts baseAppOptions as an argument. Ensure that this change does not affect the function calls elsewhere in the codebase.

  • 372-508: The initialization of the TestApp has been significantly changed. The new code creates a temporary directory for the validator, writes the necessary files into it, and starts the Cosmos app using a root command. This is a major change and should be thoroughly tested to ensure it works as expected and does not introduce any new issues.

  • 510-513: The DisableUpdateMonitoringForTesting function is now called only if usesDefaultAppConfig is true. Ensure that this change does not affect the behavior of the tests.

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.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between f2150de and b25fc58.
Files ignored due to filter (2)
  • protocol/go.mod
  • protocol/go.sum
Files selected for processing (1)
  • protocol/testutil/app/app.go (5 hunks)
Additional comments: 4
protocol/testutil/app/app.go (4)
  • 63-85: The addition of alicePrivValidatorKeyJson and aliceNodeKeyJson constants is a good practice for maintaining consistency and readability. However, it's important to ensure that these keys are only used for testing and not in production. If these keys are compromised, it could lead to security vulnerabilities.

  • 295-300: The removal of baseAppOptions from the TestAppBuilder struct and its usage in the codebase should be verified. If there are any dependencies on baseAppOptions in the existing code, they should be updated or removed accordingly.

  • 309-316: The WithAppOptions function has been updated to remove the baseAppOptions parameter. This change should be verified across the codebase to ensure that all calls to this function have been updated to match the new signature.

  • 372-511: The changes in this hunk are significant and involve the initialization of the test application. The application is now started using the command line, which allows for flag-based testing and daemon setup on app start-up. This is a good practice for testing as it closely mimics the actual application start-up process. However, it's important to ensure that all dependencies and configurations are correctly set up for this new initialization process. The use of a temporary directory for validators and the launching of the application in a separate goroutine are good practices for improving testing efficiency. However, the use of hardcoded flags and the disabling of certain daemons should be reviewed and possibly made configurable to allow for more flexible testing.

- 	"start",
- 	// Do not start tendermint.
- 	"--grpc-only",
- 	"true",
- 	"--home",
- 	validatorHomeDir,
- 	// TODO(CORE-29): Allow the daemons to be launched and cleaned-up successfully by default.
- 	"--price-daemon-enabled",
- 	"false",
- 	"--bridge-daemon-enabled",
- 	"false",
- 	"--liquidation-daemon-enabled",
- 	"false",
+ 	"start",
+ 	"--grpc-only",
+ 	tApp.builder.appOptions["grpc-only"],
+ 	"--home",
+ 	validatorHomeDir,
+ 	"--price-daemon-enabled",
+ 	tApp.builder.appOptions["price-daemon-enabled"],
+ 	"--bridge-daemon-enabled",
+ 	tApp.builder.appOptions["bridge-daemon-enabled"],
+ 	"--liquidation-daemon-enabled",
+ 	tApp.builder.appOptions["liquidation-daemon-enabled"],
Committable suggestion (Beta)
	// Specify the start-up flags.
	rootCmd.SetArgs([]string{
		"start",
		"--grpc-only",
		tApp.builder.appOptions["grpc-only"],
		"--home",
		validatorHomeDir,
		"--price-daemon-enabled",
		tApp.builder.appOptions["price-daemon-enabled"],
		"--bridge-daemon-enabled",
		tApp.builder.appOptions["bridge-daemon-enabled"],
		"--liquidation-daemon-enabled",
		tApp.builder.appOptions["liquidation-daemon-enabled"],
	})

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.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 8933f1f and 5283734.
Files ignored due to filter (2)
  • protocol/go.mod
  • protocol/go.sum
Files selected for processing (8)
  • protocol/app/ante/gas_test.go (2 hunks)
  • protocol/app/app_test.go (1 hunks)
  • protocol/app/prepare/full_node_prepare_proposal_test.go (1 hunks)
  • protocol/cmd/dydxprotocold/cmd/config.go (2 hunks)
  • protocol/cmd/dydxprotocold/cmd/root.go (5 hunks)
  • protocol/testutil/app/app.go (6 hunks)
  • protocol/x/clob/e2e/order_removal_test.go (2 hunks)
  • protocol/x/sending/app_test.go (5 hunks)
Files skipped from review due to trivial changes (5)
  • protocol/app/ante/gas_test.go
  • protocol/app/app_test.go
  • protocol/app/prepare/full_node_prepare_proposal_test.go
  • protocol/x/clob/e2e/order_removal_test.go
  • protocol/x/sending/app_test.go
Additional comments: 15
protocol/cmd/dydxprotocold/cmd/config.go (2)
  • 34-34: The function signature of initAppConfig has been changed to return a pointer to DydxAppConfig instead of an interface{}. This change improves type safety and should help prevent runtime type assertion errors. However, please ensure that all calls to this function throughout the codebase have been updated to handle the new return type.

  • 71-71: The appConfig is now returned as a pointer. This is a good practice as it can help to reduce memory usage by avoiding copying the entire struct when the function returns. However, please ensure that the returned pointer is not being dereferenced without a nil check in the calling code.

protocol/testutil/app/app.go (6)
  • 5-19: The new imports introduced in this hunk are necessary for the changes made in the rest of the file. They are all standard libraries or well-known packages, so there should be no issues with them.

  • 63-85: The addition of alicePrivValidatorKeyJson and aliceNodeKeyJson constants is a good practice for maintaining hardcoded values. These constants are used later in the launchValidator function to create the necessary configuration files for the validator.

  • 295-300: The baseAppOptions field has been removed from the TestAppBuilder struct. This change simplifies the struct and removes an unnecessary dependency on baseapp.BaseApp. However, ensure that this does not affect the functionality of the test application.

  • 309-316: The WithAppOptions function has been updated to remove the baseAppOptions parameter. This change simplifies the function and removes an unnecessary dependency on baseapp.BaseApp. However, ensure that this does not affect the functionality of the test application.

  • 372-405: The TestApp initialization process has been significantly modified. The launchValidator function is now used to start the application, which allows for more control over the application's configuration and lifecycle. This change improves the flexibility and robustness of the test framework.

  • 663-791: The launchValidator function is a new addition that starts a validator using the start command with the specified genesis doc and application options. This function provides a more controlled way to launch a validator for testing purposes. It also includes proper cleanup procedures to ensure that resources are freed after the test.

protocol/cmd/dydxprotocold/cmd/root.go (7)
  • 53-68: The NewRootCmd function has been updated to use NewRootCmdWithInterceptors function. This change allows for server and app configuration customization through interceptors. The interceptors are functions that are passed as arguments and are called at specific points in the initialization process. This is a good practice as it allows for more flexible and customizable code. However, ensure that the interceptors are used correctly and safely throughout the codebase.

  • 70-75: The NewRootCmdWithInterceptors function has been added. This function takes in interceptors for the server context, app configuration, and app itself. These interceptors allow for customization of the server context, app configuration, and app during the initialization process. This is a good practice as it allows for more flexible and customizable code. However, ensure that the interceptors are used correctly and safely throughout the codebase.

  • 110-110: The appConfigInterceptor function is now being used to get the app configuration. This allows for customization of the app configuration during the initialization process. Ensure that the interceptor is used correctly and safely throughout the codebase.

  • 122-122: The serverCtxInterceptor function is now being used to customize the server context. This allows for customization of the server context during the initialization process. Ensure that the interceptor is used correctly and safely throughout the codebase.

  • 129-140: The initRootCmd function now takes in an appInterceptor function as an argument. This allows for customization of the app during the initialization process. Ensure that the interceptor is used correctly and safely throughout the codebase.

  • 163-165: The appInterceptor function is now being used to create the app. This allows for customization of the app during the initialization process. Ensure that the interceptor is used correctly and safely throughout the codebase.

  • 256-256: The return type of the newApp method has been changed from servertypes.Application to *dydxapp.App. This improves type safety by returning a more specific type. Ensure that all calls to this method throughout the codebase have been updated to handle the new return type.

serverCtxPtr.Logger = logger.(log.Logger)
}
},
// Override the addresses to use domain sockets to avoid port conflicts.
Copy link
Contributor

Choose a reason for hiding this comment

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

niiiiice

}

shutdownFn = func() error {
cancelFn()
Copy link
Contributor

@clemire clemire Oct 25, 2023

Choose a reason for hiding this comment

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

Why are we maybe calling cancelFn twice? It's definitely called on line 779, right?

Copy link
Contributor Author

@lcwik lcwik Oct 25, 2023

Choose a reason for hiding this comment

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

Previous comment didn't make sense.

The first invocation is to cancelFn is in the case where creating the Cosmos app errored and I want to cancel the context so that any resources that Cosmos created that uses it are cleaned up.

The second invocation is inside a lambda that is used by the caller of this method to shutdown the Cosmos app and represents the case where we created the Cosmos app successfully.

Copy link
Contributor

Choose a reason for hiding this comment

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

ICIC, go case statements do not fall through.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that is right

… app using cmd.

This works towards enabling and passing in flags for flag based testing.
This also works towards enabling daemons on e2e app start-up once the daemons can be cleaned up.
This relies on dydxprotocol/cosmos-sdk#29
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.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between b6f48a3 and e688197.
Files ignored due to filter (2)
  • protocol/go.mod
  • protocol/go.sum
Files selected for processing (8)
  • protocol/app/ante/gas_test.go (2} hunks)
  • protocol/app/app_test.go (1} hunks)
  • protocol/app/prepare/full_node_prepare_proposal_test.go (1} hunks)
  • protocol/cmd/dydxprotocold/cmd/config.go (2} hunks)
  • protocol/cmd/dydxprotocold/cmd/root.go (5} hunks)
  • protocol/testutil/app/app.go (6} hunks)
  • protocol/x/clob/e2e/order_removal_test.go (2} hunks)
  • protocol/x/sending/app_test.go (5} hunks)
Files skipped from review due to trivial changes (5)
  • protocol/app/ante/gas_test.go
  • protocol/app/app_test.go
  • protocol/app/prepare/full_node_prepare_proposal_test.go
  • protocol/x/clob/e2e/order_removal_test.go
  • protocol/x/sending/app_test.go
Additional comments: 14
protocol/cmd/dydxprotocold/cmd/config.go (2)
  • 34-34: The function signature of initAppConfig has been updated to return a pointer to a DydxAppConfig struct instead of an interface{}. This change improves type safety and allows for better compile-time checks. Ensure that all calls to this function throughout the codebase have been updated to handle the new return type.

  • 71-71: The initAppConfig function now returns a pointer to the appConfig struct. This is a good practice as it avoids copying the struct and can improve performance, especially if the struct is large. However, be aware that any modifications to the returned struct will affect the original appConfig due to the nature of pointers.

protocol/cmd/dydxprotocold/cmd/root.go (6)
  • 53-68: The NewRootCmd function has been updated to use NewRootCmdWithInterceptors. This change allows for the customization of server and app configurations through the use of interceptors. This is a good practice as it provides flexibility and makes the code more adaptable to changes in the future. However, ensure that the interceptors are used correctly throughout the codebase to avoid potential issues.

  • 110-110: The appConfigInterceptor function is now used to initialize the app configuration. This change improves the flexibility of the app configuration process, but it's important to ensure that the interceptor function is implemented correctly and returns a valid app configuration.

  • 122-122: The serverCtxInterceptor function is now used to modify the server context. This change improves the flexibility of the server context setup process, but it's important to ensure that the interceptor function is implemented correctly and modifies the server context as intended.

  • 129-140: The initRootCmd function now takes an additional appInterceptor argument. This change allows for the customization of the app during the initialization of the root command. This is a good practice as it provides flexibility and makes the code more adaptable to changes in the future. However, ensure that the interceptor is used correctly throughout the codebase to avoid potential issues.

  • 163-165: The server.AddCommands function now uses the appInterceptor function to create a new app. This change improves the flexibility of the app creation process, but it's important to ensure that the interceptor function is implemented correctly and returns a valid app.

  • 256-256: The return type of the newApp function has been changed from servertypes.Application to *dydxapp.App. This change improves type safety and makes the code more readable. However, ensure that all calls to this function throughout the codebase have been updated to match the new return type.

protocol/testutil/app/app.go (6)
  • 5-22: The new hunk introduces several new imports that are used in the updated code. These imports are necessary for the new functionality being added, such as starting the Cosmos app using the command line and setting up the necessary environment for testing.

  • 63-85: The new hunk introduces two constants alicePrivValidatorKeyJson and aliceNodeKeyJson which are used to set up the validator's home directory in the launchValidator function. This is a part of the new functionality to start the Cosmos app using the command line for testing.

  • 300-305: The baseAppOptions field has been removed from the TestAppBuilder struct. This change is consistent with the removal of the baseAppOptions parameter from the WithAppOptions function. The baseAppOptions were previously used to customize the BaseApp instance, but it seems that this customization is no longer necessary or has been moved elsewhere.

  • 314-321: The WithAppOptions function has been updated to remove the baseAppOptions parameter. This change is consistent with the removal of the baseAppOptions field from the TestAppBuilder struct. The baseAppOptions were previously used to customize the BaseApp instance, but it seems that this customization is no longer necessary or has been moved elsewhere.

  • 377-410: The new hunk introduces a significant change in the way the test application is initialized. Instead of using the DefaultTestApp function to create the application, the launchValidator function is used. This function starts the Cosmos app using the command line, which allows for more flexibility in testing. The launchValidator function also sets up the necessary environment for testing, including creating a temporary directory for the validator's home directory and setting up the necessary configuration files.

  • 672-802: The new hunk introduces the launchValidator function, which starts the Cosmos app using the command line for testing. This function creates a temporary directory for the validator's home directory, sets up the necessary configuration files, and starts the Cosmos app using the NewRootCmdWithInterceptors function. The launchValidator function also returns a shutdownFn function that can be used to stop the execution of the app. This function significantly enhances the flexibility and robustness of the testing environment.

@lcwik lcwik merged commit 1089ad2 into main Oct 27, 2023
15 of 16 checks passed
@lcwik lcwik deleted the lukecore29 branch October 27, 2023 02:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants