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(accounts): re-introduce bundler #21562

Merged
merged 22 commits into from
Oct 25, 2024
Merged

feat(accounts): re-introduce bundler #21562

merged 22 commits into from
Oct 25, 2024

Conversation

testinginprod
Copy link
Contributor

@testinginprod testinginprod commented Sep 5, 2024

Description

Closes: #XXXX


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

    • Introduced transaction bundling functionality, allowing a bundler to submit transactions on behalf of multiple users.
    • Added a new TxExtension message to manage gas limits and payment messages for bundled transactions.
    • Enhanced MsgExecuteBundle and BundledTxResponse structures to capture detailed execution metrics.
  • Bug Fixes

    • Improved error handling in transaction authentication and execution processes.
  • Documentation

    • Updated README to describe new bundling features and transaction management enhancements.
    • Enhanced UPGRADING.md with details on changes for version 0.52.x, including transaction simulation and module updates.
  • Tests

    • Added integration tests for bundled transaction execution and account abstraction functionalities.
    • Introduced unit tests for verifying account abstraction transaction extensions.

Copy link
Contributor

coderabbitai bot commented Sep 5, 2024

Warning

Rate limit exceeded

@testinginprod has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 20 minutes and 10 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Files that changed from the base of the PR and between 7603361 and 8d347c2.

📝 Walkthrough
📝 Walkthrough
📝 Walkthrough
📝 Walkthrough

Walkthrough

The pull request introduces significant modifications to the Cosmos SDK's account management system, including the addition of a new message type TxExtension in the protobuf definitions. This message facilitates transaction handling by managing gas limits and bundler payments. Changes to existing message structures enhance the representation of bundled transactions. New integration tests are added to validate these functionalities, while utility functions and error handling improvements are introduced to support the new features. Overall, the changes enhance transaction processing and account abstraction capabilities within the SDK.

Changes

File Path Change Summary
api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go Added new message type TxExtension with fields for gas limits and bundler payments.
api/cosmos/accounts/v1/tx.pulsar.go Modified message structures, including changing MsgExecuteBundle to use byte slices and adding fields to BundledTxResponse.
simapp/app.go Added transaction decoder initialization and updated Accounts Keeper instantiation to include the decoder.
tests/e2e/accounts/account_abstraction_test.go Deleted file containing unit tests for account abstraction functionality.
tests/integration/accounts/bundler_test.go Introduced integration tests for MsgServer_ExecuteBundle, covering various transaction scenarios.
tests/integration/accounts/fixture_test.go Added integration tests setup with a mock account and fixture struct for testing context.
tests/integration/auth/keeper/fixture_test.go Updated accounts.NewKeeper call to include a new parameter in the integration test setup.
x/accounts/README.md Enhanced documentation on transaction bundling and the new TxExtension message.
x/accounts/depinject.go Added transaction decoder initialization in the dependency injection setup.
x/accounts/keeper.go Updated Keeper struct to include a transaction decoder and methods for handling multiple messages.
x/accounts/keeper_account_abstraction.go Introduced methods for executing bundled transactions and improved error handling.
x/accounts/keeper_account_abstraction_test.go Added unit tests for verifyAndExtractAaXtFromTx function to validate account abstraction logic.
x/accounts/msg_server.go Implemented logic for ExecuteBundle method to handle bundled transactions and added error handling for disabled bundling.
x/accounts/msg_server_test.go Added test for ExecuteBundle method when bundling is disabled.
x/accounts/proto/cosmos/accounts/interfaces/account_abstraction/v1/interface.proto Introduced TxExtension message with fields for gas limits and bundler payment messages.
x/accounts/proto/cosmos/accounts/v1/tx.proto Modified MsgExecuteBundle and introduced BundledTxResponse with fields for gas usage and execution responses.
x/accounts/protoutils.go Added utility functions for converting between protocol buffer versions.
x/accounts/utils_test.go Updated NewKeeper function call to include a new parameter in tests.
x/auth/tx/config.go Enhanced error handling in transaction configuration functions.
x/tx/go.mod Added indirect dependency for github.com/rogpeppe/go-internal v1.11.0.

Possibly related PRs

  • feat(auth): allow BaseAccounts to be migrated to x/accounts #21820: The changes in the main PR regarding the MsgExecuteBundle and BundledTxResponse structures are related to the migration feature introduced in this PR, which allows BaseAccounts to be migrated to the x/accounts module, as it involves similar message structures and handling of account-related transactions.
  • docs(x/accounts): init of the x/accounts module docs. #22099: The documentation enhancements in this PR for the x/accounts module directly relate to the changes made in the main PR, as they both focus on the functionality and structure of account messages, including MsgExecuteBundle and BundledTxResponse.
  • docs(x/accounts): fix doc #22295: This PR also enhances the documentation for the x/accounts module, which aligns with the changes in the main PR that modify the message structures and their handling, particularly around account initialization and execution.

Suggested reviewers

  • sontrinh16
  • julienrbrt
  • akhilkumarpilli
  • facundomedica

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>, please review it.
    • 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @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.

@testinginprod testinginprod added the backport/v0.52.x PR scheduled for inclusion in the v0.52's next stable release label Sep 9, 2024
@julienrbrt julienrbrt mentioned this pull request Sep 16, 2024
10 tasks
x.ExecutionGasLimit = value.Uint()
default:
if fd.IsExtension() {
panic(fmt.Errorf("proto3 declared messages do not support extensions: cosmos.accounts.interfaces.account_abstraction.v1.TxExtension"))

Check warning

Code scanning / CodeQL

Panic in BeginBock or EndBlock consensus methods Warning

Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
if fd.IsExtension() {
panic(fmt.Errorf("proto3 declared messages do not support extensions: cosmos.accounts.interfaces.account_abstraction.v1.TxExtension"))
}
panic(fmt.Errorf("message cosmos.accounts.interfaces.account_abstraction.v1.TxExtension does not contain field %s", fd.FullName()))

Check warning

Code scanning / CodeQL

Panic in BeginBock or EndBlock consensus methods Warning

Possible panics in BeginBock- or EndBlock-related consensus methods could cause a chain halt
"github.com/cosmos/cosmos-sdk/types/tx/signing"
)

func protoV2TxToProtoV1(t *txv1beta1.Tx) *tx.Tx {
Copy link
Member

Choose a reason for hiding this comment

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

Why don't we just marshal and unmarshal? This is probably marginally faster but less safe.

@testinginprod testinginprod marked this pull request as ready for review October 10, 2024 12:59
Copy link
Contributor

@testinginprod your pull request is missing a changelog!

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: 26

🧹 Outside diff range and nitpick comments (22)
x/accounts/msg_server_test.go (1)

47-58: LGTM! Consider adding a descriptive comment.

The new test function TestMsgServer_BundlingDisabled is well-structured and effectively tests the behavior when bundling is disabled. It follows Go testing best practices and provides good coverage for this scenario.

To improve clarity, consider adding a brief comment explaining the purpose of this test at the beginning of the function.

 func TestMsgServer_BundlingDisabled(t *testing.T) {
+	// Test that attempting to execute a bundle when bundling is disabled returns ErrBundlingDisabled
 	k, ctx := newKeeper(t, accountstd.AddAccount("test", NewTestAccount))
 	k.DisableTxBundling()
x/accounts/README.md (2)

602-617: Minor style improvements suggested

Consider the following style improvements:

  1. Use consistent list item prefixes. Change the numbered list to use "1." for all items instead of "1.", "2.", "3.", "4.".
  2. For the nested list under bundler_payment_messages, consider using asterisks (*) instead of dashes (-) for consistency with other unordered lists in the document.
🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


605-605: Minor grammatical improvement suggested

To improve clarity, consider rephrasing the sentence:

- Can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.
+ It can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.

This change forms a complete sentence and improves readability.

🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

x/accounts/protoutils.go (2)

40-46: Consider inlining simple functions

The function protoV2TimestampToV1 is simple and used only once. Consider inlining it to reduce redundancy.

You can replace its usage directly in protoV2TxToProtoV1:

-   timeoutTimestamp := protoV2TimestampToV1(t.Body.TimeoutTimestamp)
+   var timeoutTimestamp *time.Time
+   if t.Body.TimeoutTimestamp != nil {
+       ts := t.Body.TimeoutTimestamp.AsTime()
+       timeoutTimestamp = &ts
+   }

And remove the protoV2TimestampToV1 function if it's no longer needed.


6-8: Group standard library imports separately

According to the Uber Go Style Guide, standard library imports should be grouped separately from third-party imports.

Reorganize the imports:

 import (
     "time"

+    "errors"
+
     "google.golang.org/protobuf/types/known/anypb"
     "google.golang.org/protobuf/types/known/timestamppb"

     // ...
 )
x/accounts/proto/cosmos/accounts/v1/tx.proto (1)

84-104: Enhance comments and formatting for BundledTxResponse message

The comments for the BundledTxResponse message are misaligned and could be improved for clarity. According to Protobuf style guidelines, comments should be placed directly above the message or field they describe, without extra indentation. Additionally, providing a comprehensive description enhances readability.

Consider updating the comments as follows:

-// BundledTxResponse defines the response of a bundled tx.
-  // If the operation fails the error field will be populated, the used gas fields will also be
-  // populated depending on when the execution stopped. Bundler payment responses will be populated
-  // if the execution fails.
 message BundledTxResponse {
+// BundledTxResponse defines the response of a bundled transaction.
+// If the operation fails, the `error` field will be populated.
+// The gas usage fields will reflect the gas consumed up to the point of failure.
+// `bundler_payment_responses` will be populated if the execution fails.
x/accounts/keeper_account_abstraction_test.go (3)

18-19: Use fixed timestamps for deterministic tests

Using time.Now() in tests can lead to non-deterministic behavior and flaky tests. Consider using a fixed currentTime to ensure that tests are repeatable and independent of the system clock.

Apply this diff to set a fixed timestamp:

-currentTime := time.Now()
+currentTime := time.Unix(1696200000, 0) // Fixed timestamp for test determinism

217-228: Use require for critical assertions to halt on failure

In the test loop, using require instead of assert for error checks ensures that the test stops immediately upon failure, preventing subsequent assertions from running with invalid states.

Apply this diff to switch to require:

-			assert.Error(t, err)
-			assert.Contains(t, err.Error(), tt.wantErr)
+			require.Error(t, err)
+			require.Contains(t, err.Error(), tt.wantErr)

21-26: Include comments to clarify test setup variables

Adding comments to explain the purpose and structure of validXt enhances readability and helps other developers understand the test setup more easily.

x/accounts/keeper_account_abstraction.go (3)

Line range hint 24-31: Enhance readability by adjusting error variable declarations

The error variable declarations include inline comments, which may affect readability. Consider placing comments above each error variable to enhance clarity, following Go conventions.

Apply this diff:

 var (
-	ErrAASemantics = errors.New("invalid account abstraction tx semantics")
-	// ErrAuthentication is returned when the authentication fails.
-	ErrAuthentication = errors.New("authentication failed")
-	// ErrBundlerPayment is returned when the bundler payment fails.
-	ErrBundlerPayment = errors.New("bundler payment failed")
-	// ErrExecution is returned when the execution fails.
-	ErrExecution = errors.New("execution failed")
+	// ErrAASemantics is returned when the account abstraction transaction semantics are invalid.
+	ErrAASemantics = errors.New("invalid account abstraction tx semantics")
+
+	// ErrAuthentication is returned when the authentication fails.
+	ErrAuthentication = errors.New("authentication failed")
+
+	// ErrBundlerPayment is returned when the bundler payment fails.
+	ErrBundlerPayment = errors.New("bundler payment failed")
+
+	// ErrExecution is returned when the execution fails.
+	ErrExecution = errors.New("execution failed")
 )

164-164: Address the TODO comment regarding timeout checks

The TODO comment indicates concerns about code repetition in the timeout verification logic. Refactoring the timeout checks into a separate helper function can reduce duplication and enhance maintainability.

Would you like assistance in refactoring this code segment as suggested above?


203-206: Implement validation logic in verifyAaXt function

The verifyAaXt function currently does not perform any checks and simply returns nil. Consider implementing the necessary validation logic for TxExtension to ensure the integrity of the transaction extension.

Would you like assistance in implementing this validation logic?

tests/integration/accounts/fixture_test.go (1)

57-57: Add comment to explain empty RegisterQueryHandlers implementation

The RegisterQueryHandlers method in mockAccount is empty, which might cause confusion for future maintainers. Adding a comment clarifies that no query handlers are needed for this mock account.

Apply this diff to add an explanatory comment:

func (m mockAccount) RegisterQueryHandlers(_ *accountstd.QueryBuilder) {
+	// No query handlers to register for mockAccount.
}
x/accounts/keeper.go (1)

Line range hint 85-107: Inconsistent Method Receivers in Keeper Struct

The Keeper struct methods predominantly use value receivers (e.g., func (k Keeper)), but the newly added DisableTxBundling method uses a pointer receiver (k *Keeper).

For consistency and to avoid potential confusion, it's recommended to use the same receiver type for all methods of a struct. Since DisableTxBundling modifies the receiver's state, using pointer receivers for all methods is advisable. This also ensures that any modifications to the Keeper instance persist across method calls.

Consider refactoring the Keeper struct methods to use pointer receivers:

-// Existing method with value receiver
-func (k Keeper) SomeMethod() {
+// Refactored method with pointer receiver
+func (k *Keeper) SomeMethod() {
     // method implementation
 }
simapp/app.go (1)

220-226: Consider enhancing the panic message for better debugging.

While panicking on initialization errors is acceptable, adding more context to the panic message can aid in debugging.

You could modify the panic call to include additional context:

if err != nil {
-    panic(err)
+    panic(fmt.Errorf("failed to create txDecoder: %w", err))
}
api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go (2)

2649-2649: Correct pluralization in the comment for TxExtension

In the comment for the TxExtension struct, "AA's" is used to denote a plural, but the apostrophe indicates possession. It should be "AAs" without an apostrophe to represent the plural form of "Account Abstractions".

Apply this diff to correct the comment:

-// TxExtension is the extension option that AA's add to txs when they're bundled.
+// TxExtension is the extension option that AAs add to txs when they're bundled.

2655-2676: Enclose field names in backticks within comments for clarity

For improved readability and to adhere to the Go documentation conventions, consider enclosing field names in backticks within the comments. This makes it clear when you are referring to code identifiers.

Apply these changes to the field comments:

-// authentication_gas_limit expresses the gas limit to be used for the authentication part of the
+// `AuthenticationGasLimit` expresses the gas limit to be used for the authentication part of the
 // bundled tx.

-// bundler_payment_messages expresses a list of messages that the account
+// `BundlerPaymentMessages` expresses a list of messages that the account
 // executes to pay the bundler for submitting the bundled tx.
 // It can be empty if the bundler does not need any form of payment,
 // the handshake for submitting the UserOperation might have happened off-chain.
 // Bundlers and accounts are free to use any form of payment, in fact the payment can
 // either be empty or be expressed as:
 // - NFT payment
 // - IBC Token payment.
 // - Payment through delegations.

-// bundler_payment_gas_limit defines the gas limit to be used for the bundler payment.
+// `BundlerPaymentGasLimit` defines the gas limit to be used for the bundler payment.
 // This ensures that, since the bundler executes a list of bundled tx and there needs to
 // be minimal trust between bundler and the tx sender, the sender cannot consume
 // the whole bundle gas.

-// execution_gas_limit defines the gas limit to be used for the execution of the UserOperation's
+// `ExecutionGasLimit` defines the gas limit to be used for the execution of the UserOperation's
 // execution messages.
api/cosmos/accounts/v1/tx.pulsar.go (1)

2604-2604: Simplify slice initialization by removing unnecessary nil check

In Go, appending to a nil slice initializes it automatically. The check if x.Txs == nil { x.Txs = [][]byte{} } is unnecessary and can be omitted. This simplifies the code and aligns with Go idioms.

x/accounts/proto/cosmos/accounts/interfaces/account_abstraction/v1/interface.proto (4)

44-45: Consider replacing "expresses" with "specifies" for clarity

In the comment for authentication_gas_limit, using "specifies" would improve clarity and align with common terminology.

Suggested change:

-// authentication_gas_limit expresses the gas limit to be used for the authentication part of the
+// authentication_gas_limit specifies the gas limit to be used for the authentication part of the

47-47: Consider replacing "expresses" with "specifies" for clarity

Similarly, in the comment for bundler_payment_messages, replacing "expresses" with "specifies" may enhance understanding.

Suggested change:

-// bundler_payment_messages expresses a list of messages that the account
+// bundler_payment_messages specifies a list of messages that the account

53-55: Ensure consistent punctuation in list items

The list items in the comment have inconsistent punctuation. To improve readability, add periods to all items or remove them uniformly.

Suggested change:

 // - NFT payment
+// - NFT payment.
 // - IBC Token payment.
 // - Payment through delegations.

Alternatively, remove periods from the other items:

-// - IBC Token payment.
+// - IBC Token payment
-// - Payment through delegations.
+// - Payment through delegations

58-60: Simplify the comment for better readability

The sentence in the comment for bundler_payment_gas_limit is complex. Consider rephrasing it to enhance clarity.

Suggested change:

-// This ensures that, since the bundler executes a list of bundled tx and there needs to
-// be minimal trust between bundler and the tx sender, the sender cannot consume
-// the whole bundle gas.
+// This ensures that the sender cannot consume the entire gas allocated for the bundle,
+// as there is minimal trust between the bundler and the sender.
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3a03804 and ad28604.

⛔ Files ignored due to path filters (3)
  • x/accounts/interfaces/account_abstraction/v1/interface.pb.go is excluded by !**/*.pb.go
  • x/accounts/v1/tx.pb.go is excluded by !**/*.pb.go
  • x/tx/go.sum is excluded by !**/*.sum
📒 Files selected for processing (20)
  • api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go (6 hunks)
  • api/cosmos/accounts/v1/tx.pulsar.go (27 hunks)
  • simapp/app.go (3 hunks)
  • tests/e2e/accounts/account_abstraction_test.go (0 hunks)
  • tests/integration/accounts/bundler_test.go (1 hunks)
  • tests/integration/accounts/fixture_test.go (1 hunks)
  • tests/integration/auth/keeper/fixture_test.go (1 hunks)
  • x/accounts/README.md (1 hunks)
  • x/accounts/depinject.go (2 hunks)
  • x/accounts/keeper.go (6 hunks)
  • x/accounts/keeper_account_abstraction.go (3 hunks)
  • x/accounts/keeper_account_abstraction_test.go (1 hunks)
  • x/accounts/msg_server.go (3 hunks)
  • x/accounts/msg_server_test.go (1 hunks)
  • x/accounts/proto/cosmos/accounts/interfaces/account_abstraction/v1/interface.proto (2 hunks)
  • x/accounts/proto/cosmos/accounts/v1/tx.proto (1 hunks)
  • x/accounts/protoutils.go (1 hunks)
  • x/accounts/utils_test.go (1 hunks)
  • x/auth/tx/config.go (1 hunks)
  • x/tx/go.mod (1 hunks)
💤 Files with no reviewable changes (1)
  • tests/e2e/accounts/account_abstraction_test.go
🧰 Additional context used
📓 Path-based instructions (16)
api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go (1)

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

api/cosmos/accounts/v1/tx.pulsar.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.

tests/integration/accounts/bundler_test.go (3)

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


Pattern tests/**/*: "Assess the integration and e2e test code assessing sufficient code coverage for the changes associated in the pull request"


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

tests/integration/accounts/fixture_test.go (3)

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


Pattern tests/**/*: "Assess the integration and e2e test code assessing sufficient code coverage for the changes associated in the pull request"


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

tests/integration/auth/keeper/fixture_test.go (3)

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


Pattern tests/**/*: "Assess the integration and e2e test code assessing sufficient code coverage for the changes associated in the pull request"


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

x/accounts/README.md (1)

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

x/accounts/depinject.go (1)

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

x/accounts/keeper.go (1)

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

x/accounts/keeper_account_abstraction.go (1)

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

x/accounts/keeper_account_abstraction_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"

x/accounts/msg_server.go (1)

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

x/accounts/msg_server_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"

x/accounts/protoutils.go (1)

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

x/accounts/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"

x/auth/tx/config.go (1)

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

📓 Learnings (1)
x/accounts/msg_server.go (2)
Learnt from: testinginprod
PR: cosmos/cosmos-sdk#18499
File: x/accounts/msg_server.go:123-125
Timestamp: 2023-11-20T18:30:34.484Z
Learning: The `ExecuteBundle` method in `x/accounts/msg_server.go` is intentionally left unimplemented and is expected to be addressed in a follow-up PR.
Learnt from: testinginprod
PR: cosmos/cosmos-sdk#18499
File: x/accounts/msg_server.go:123-125
Timestamp: 2024-10-08T15:31:05.486Z
Learning: The `ExecuteBundle` method in `x/accounts/msg_server.go` is intentionally left unimplemented and is expected to be addressed in a follow-up PR.
🪛 LanguageTool
x/accounts/README.md

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint
x/accounts/README.md

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

🔇 Additional comments (27)
x/tx/go.mod (1)

27-27: Verify the necessity of the new indirect dependency.

A new indirect dependency has been added: github.com/rogpeppe/go-internal v1.11.0. While indirect dependencies are typically added automatically by the Go toolchain, it's important to understand why this dependency was introduced.

To ensure this dependency is necessary and doesn't introduce any conflicts or security issues, please run the following commands:

Please review the output of these commands and confirm:

  1. If the dependency is directly used in the codebase.
  2. If removing the dependency causes any issues.
  3. If there are any known high or critical severity vulnerabilities for this package.

If the dependency is not directly used and can be removed without issues, consider removing it. If it's necessary, ensure that it doesn't introduce any security risks.

x/accounts/utils_test.go (3)

Line range hint 1-105: Overall assessment: Minimal impact on test utility

The change in the newKeeper function is isolated and doesn't affect the overall structure or purpose of the test utility. The modification is minimal and appears to be a necessary adjustment to align with changes in the main implementation.


Line range hint 1-105: Test coverage assessment

While this file is a test utility and doesn't contain direct unit tests, it plays a crucial role in facilitating testing for the accounts module. The change to the newKeeper function might impact how other tests are set up.

To ensure sufficient code coverage:

  1. Verify that existing tests using this utility still pass with the updated newKeeper function.
  2. Consider adding or updating tests in other files that specifically exercise the new parameter added to the NewKeeper function call.

To check if existing tests are affected, run:

Would you like assistance in identifying tests that might need updates or in creating new tests to cover this change?


78-78: Approve change with suggestions for improvement

The addition of the nil parameter to the NewKeeper function call appears to be correct, likely reflecting changes in the main implementation. However, to ensure clarity and maintainability:

  1. Please verify that this change is consistent with the updated NewKeeper function signature in the main implementation.
  2. Consider adding a comment explaining the purpose of this new parameter, especially since it's set to nil in the test setup.

To verify the consistency of this change, please run the following command:

Consider adding a comment above the NewKeeper call to explain the purpose of the new nil parameter:

// The nil parameter represents [explain its purpose here]
m, err := NewKeeper(codec.NewProtoCodec(ir), env, addressCodec, ir, nil, accounts...)
tests/integration/auth/keeper/fixture_test.go (1)

Line range hint 1-153: Summary: Approve changes, recommend thorough testing

The changes to this integration test file appear to be minimal and focused on updating the accounts.NewKeeper function call. While this change seems intentional and localized, it's crucial to ensure it doesn't introduce any unintended side effects in the test execution.

Recommendations:

  1. Run the entire test suite to verify that this change doesn't negatively impact any existing tests.
  2. Consider adding or updating tests specifically for the functionality related to this new parameter in the accounts.NewKeeper function.

To ensure the changes haven't introduced any regressions, please run the following command:

This will help verify that all tests in the auth keeper package still pass after this change.

x/auth/tx/config.go (2)

Line range hint 89-91: Improved error handling for SigningOptions

The addition of an early check for nil SigningOptions enhances the function's robustness and aligns with the Uber Golang style guide's recommendation for early error handling. The error message is clear and descriptive.


Line range hint 196-201: Improved error handling and decoder initialization

The changes in this segment enhance the function's robustness and correctness:

  1. The syntax error (extra comma) has been fixed.
  2. Error handling for the decoder initialization is now more comprehensive.
  3. The use of txdecode.NewDecoder ensures proper setting of both txConfig.decoder and txConfig.txDecoder.

These improvements align well with the Uber Golang style guide's recommendations for error handling and code clarity.

x/accounts/README.md (4)

542-561: LGTM: Clear introduction to transaction bundling

The introduction to transaction bundling is well-written and informative. The advantages are clearly explained, and the mermaid diagram effectively illustrates the bundling process. This section provides a solid foundation for understanding the concept.


563-617: LGTM: Comprehensive explanation of TxExtension

The Tx Extension section provides a thorough explanation of the TxExtension message, including its protobuf definition and detailed descriptions of each field. This information is crucial for developers working with bundled transactions.

🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


618-638: LGTM: Important compatibility considerations

The Compatibility section effectively highlights the potential issues that may arise when implementing bundling, particularly regarding ante handler checks. The instructions for disabling bundling are clear and concise, providing a straightforward solution for chains where bundling may not be suitable.

🧰 Tools
🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


541-638: Overall assessment: Excellent addition to the documentation

The new content on transaction bundling is a valuable addition to the x/accounts module documentation. It provides clear explanations of the bundling concept, its benefits, and important technical details such as the TxExtension message. The compatibility considerations are particularly useful for developers implementing this feature.

The minor style and grammatical issues identified can be easily addressed, and once resolved, will further enhance the already high-quality documentation.

🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

x/accounts/depinject.go (2)

10-10: LGTM!

The import statement correctly adds the txdecode package required for transaction decoding.


52-58: Proper initialization of the transaction decoder

The txDec variable is correctly initialized using txdecode.NewDecoder with the appropriate options. This ensures that transaction decoding is properly configured with the necessary signing context and codec.

x/accounts/msg_server.go (6)

5-5: Importing the 'errors' package is appropriate.

The addition of the "errors" import is necessary for error handling introduced in the code changes.


15-16: Definition of 'ErrBundlingDisabled' follows Go conventions.

Defining ErrBundlingDisabled as a package-level variable using errors.New() aligns with Go best practices for error handling.


91-93: Properly handling the case when bundling is disabled.

The conditional check for m.k.bundlingDisabled correctly prevents the execution of bundled transactions when bundling is disabled, returning the appropriate error ErrBundlingDisabled.


95-98: Validating and decoding the 'Bundler' address correctly.

The conversion of req.Bundler using m.k.addressCodec.StringToBytes and handling potential errors ensures that the bundler's address is valid before proceeding.


99-103: Efficiently processing bundled transactions.

The loop correctly iterates over req.Txs, executing each bundled transaction with m.k.ExecuteBundledTx and collecting the responses.


91-104: Verify the proper utilization of 'req.Bundler' in 'ExecuteBundledTx'.

Ensure that req.Bundler is appropriately used within m.k.ExecuteBundledTx for authorization and validation purposes. This is crucial for maintaining the security and correctness of bundled transaction execution.

Run the following script to inspect the usage of ExecuteBundledTx and confirm that req.Bundler is handled correctly:

x/accounts/proto/cosmos/accounts/v1/tx.proto (2)

109-109: Updated comment improves clarity for responses field

The revised description for the responses field in MsgExecuteBundleResponse clarifies that it contains the list of responses from the bundled transactions, enhancing the understanding of its purpose.


80-80: Verify all usages of MsgExecuteBundle and its txs field after type change

The type of the txs field in MsgExecuteBundle has been changed from repeated cosmos.tx.v1beta1.TxRaw to repeated bytes. This alteration may impact serialization/deserialization processes and any code that interacts with this field. Please ensure that all parts of the codebase that use MsgExecuteBundle and its txs field are updated to handle the new type appropriately.

You can run the following shell script to find all references to MsgExecuteBundle and its txs field:

✅ Verification successful

All usages of MsgExecuteBundle and its txs field have been correctly updated to handle the new repeated bytes type. Serialization and deserialization processes are appropriately managed, and no issues were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all usages of 'MsgExecuteBundle' and its 'txs' field.

# Search for 'MsgExecuteBundle' occurrences in proto files
rg --type proto 'MsgExecuteBundle'

# Search for usages of 'MsgExecuteBundle' in Go code
rg --type go 'MsgExecuteBundle'

# Search for code accessing the 'txs' field of 'MsgExecuteBundle'
rg --type go 'MsgExecuteBundle.*\.txs'

Length of output: 29494


Script:

#!/bin/bash
# Description: Find all usages of 'MsgExecuteBundle' in proto files and code interacting with the 'txs' field.

# Search for 'MsgExecuteBundle' occurrences in proto files
rg 'MsgExecuteBundle' --glob '*.proto'

# Search for code accessing the 'txs' field of 'MsgExecuteBundle'
rg 'MsgExecuteBundle.*\.txs' --type go

Length of output: 1153


Script:

#!/bin/bash
# Description: Extract and inspect usages of 'txs' field in MsgExecuteBundle within tx.pulsar.go

# Extract lines where 'MsgExecuteBundle.txs' is accessed
rg 'MsgExecuteBundle\.txs' api/cosmos/accounts/v1/tx.pulsar.go

Length of output: 358


Script:

#!/bin/bash
# Description: Extract surrounding context for each 'case "cosmos.accounts.v1.MsgExecuteBundle.txs":' in tx.pulsar.go

# Use grep with -C to get context lines around each match
rg 'case "cosmos\.accounts\.v1\.MsgExecuteBundle\.txs":' -A 5 -B 5 api/cosmos/accounts/v1/tx.pulsar.go

Length of output: 3019

x/accounts/keeper.go (1)

369-398: Efficient Handling in sendManyMessages Functions

The newly added sendManyMessagesReturnAnys and sendManyMessages functions effectively process multiple messages, handle errors appropriately, and collect responses efficiently.

simapp/app.go (2)

81-81: Import statement for txdecode is properly added.

The new import txdecode "cosmossdk.io/x/tx/decode" is correctly grouped with other module imports.


319-319: Passing txDecoder to accounts.NewKeeper is appropriate.

The inclusion of txDecoder as a parameter enhances the accounts keeper's ability to process transactions effectively.

api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go (1)

2892-2903: Ensure generated code adheres to style guidelines

The Exporter function for TxExtension is part of the generated code. While modifications to generated code can be overwritten, if possible, consider ensuring that the code generation templates produce code that conforms to the Uber Go Style Guide.

To check if the code generator can be configured to adhere to the style guide, review the code generation settings or templates.

api/cosmos/accounts/v1/tx.pulsar.go (1)

7-7: Verify the necessity of the underscore import

The underscore import of "cosmossdk.io/api/cosmos/tx/v1beta1" indicates that the package is imported for its side effects. Please verify if these side effects are required. If not, consider removing the import to simplify dependencies.

x/accounts/proto/cosmos/accounts/interfaces/account_abstraction/v1/interface.proto (1)

42-64: LGTM!

The TxExtension message is well-structured, and the fields are appropriately defined. The additions align with the objectives to enhance transaction processing and account abstraction capabilities within the SDK.

Comment on lines +53 to +57
_, err := s.ExecuteBundle(ctx, &v1.MsgExecuteBundle{
Bundler: "someone",
Txs: nil,
})
require.ErrorIs(t, err, ErrBundlingDisabled)
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Enhance error checking for more robust testing.

While the current error check is correct, it could be more specific to ensure the exact error is returned. Consider using require.EqualError to verify both the error type and its message.

-	require.ErrorIs(t, err, ErrBundlingDisabled)
+	require.EqualError(t, err, ErrBundlingDisabled.Error(), "Expected ErrBundlingDisabled error")

This change will make the test more robust by checking both the error type and its message.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
_, err := s.ExecuteBundle(ctx, &v1.MsgExecuteBundle{
Bundler: "someone",
Txs: nil,
})
require.ErrorIs(t, err, ErrBundlingDisabled)
_, err := s.ExecuteBundle(ctx, &v1.MsgExecuteBundle{
Bundler: "someone",
Txs: nil,
})
require.EqualError(t, err, ErrBundlingDisabled.Error(), "Expected ErrBundlingDisabled error")

@@ -79,6 +79,7 @@ func initFixture(t *testing.T, extraAccs map[string]accountstd.Interface) *fixtu
runtime.NewEnvironment(runtime.NewKVStoreService(keys[accounts.StoreKey]), log.NewNopLogger(), runtime.EnvWithQueryRouterService(queryRouter), runtime.EnvWithMsgRouterService(router)),
addresscodec.NewBech32Codec("cosmos"),
cdc.InterfaceRegistry(),
nil,
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Codebase verification

Inconsistent Parameter Count for accounts.NewKeeper

The accounts.NewKeeper function is called with only one parameter in both of the following test files:

  • tests/integration/accounts/fixture_test.go: 1 parameter
  • tests/integration/auth/keeper/fixture_test.go: 1 parameter

However, the review comment indicated that a nil parameter was added to the accounts.NewKeeper call in tests/integration/auth/keeper/fixture_test.go. This suggests that the nil parameter was not actually added, leading to an inconsistency.

Please ensure that the nil parameter is correctly added to all relevant instances of accounts.NewKeeper to maintain consistency and prevent potential issues.

🔗 Analysis chain

Approve change, but clarification needed on new parameter

The addition of the nil parameter to accounts.NewKeeper appears to be intentional and part of a larger update to the function signature. However, a few points need attention:

  1. Could you please clarify the purpose of this new parameter? Understanding its role will help ensure it's being used correctly in the test setup.

  2. If this parameter represents a new feature or configuration option, consider updating the related documentation to reflect this change.

  3. It would be beneficial to verify if this change has been consistently applied across all relevant test files to maintain consistency in the test suite.

To ensure consistency across test files, please run the following command:

This will help identify if the change has been applied consistently across all test files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for all occurrences of accounts.NewKeeper in test files
rg --type go -g '*_test.go' 'accounts\.NewKeeper\(' tests/

Length of output: 212


Script:

#!/bin/bash
# Search for all occurrences of accounts.NewKeeper in test files
rg --type go -g '*_test.go' 'accounts\.NewKeeper\(' tests/

Length of output: 237


Script:

#!/bin/bash
# Count the number of parameters passed to accounts.NewKeeper in test files
rg --type go -g '*_test.go' 'accounts\.NewKeeper\(' tests/ | while read -r line; do
  file=$(echo "$line" | cut -d: -f1)
  params=$(echo "$line" | awk -F'(' '{print $2}' | tr -d ')' | tr ',' '\n' | wc -l)
  echo "$file: $params parameters"
done

Length of output: 1028

Comment on lines +56 to +58
if err != nil {
panic(err)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Consider handling the error without panicking

Currently, if txdecode.NewDecoder returns an error, the code panics. It's generally preferable to handle errors gracefully or return them to the caller, allowing for better error management and avoiding abrupt termination.

Apply this diff to return the error instead of panicking:

 func ProvideModule(in ModuleInputs) ModuleOutputs {
     accCreators := make([]accountstd.AccountCreatorFunc, len(in.Accounts))
     for i, acc := range in.Accounts {
         accCreators[i] = acc.MakeAccount
     }

     txDec, err := txdecode.NewDecoder(txdecode.Options{
         SigningContext: in.Registry.SigningContext(),
         ProtoCodec:     in.Cdc,
     })
     if err != nil {
-        panic(err)
+        panic(fmt.Errorf("failed to create transaction decoder: %w", err))
     }

     accountsKeeper, err := NewKeeper(
         in.Cdc, in.Environment, in.AddressCodec, in.Registry, txDec,
         accCreators...,
     )
     if err != nil {
         panic(err)
     }
     m := NewAppModule(in.Cdc, accountsKeeper)
     return ModuleOutputs{AccountsKeeper: accountsKeeper, Module: m}
 }

Alternatively, if modifying the function signature is feasible, consider returning an error:

-func ProvideModule(in ModuleInputs) ModuleOutputs {
+func ProvideModule(in ModuleInputs) (ModuleOutputs, error) {
     accCreators := make([]accountstd.AccountCreatorFunc, len(in.Accounts))
     for i, acc := range in.Accounts {
         accCreators[i] = acc.MakeAccount
     }

     txDec, err := txdecode.NewDecoder(txdecode.Options{
         SigningContext: in.Registry.SigningContext(),
         ProtoCodec:     in.Cdc,
     })
     if err != nil {
-        panic(err)
+        return ModuleOutputs{}, err
     }

     accountsKeeper, err := NewKeeper(
         in.Cdc, in.Environment, in.AddressCodec, in.Registry, txDec,
         accCreators...,
     )
     if err != nil {
-        panic(err)
+        return ModuleOutputs{}, err
     }
     m := NewAppModule(in.Cdc, accountsKeeper)
-    return ModuleOutputs{AccountsKeeper: accountsKeeper, Module: m}
+    return ModuleOutputs{AccountsKeeper: accountsKeeper, Module: m}, nil
 }

This change would allow the caller to handle the error appropriately.

Committable suggestion was skipped due to low confidence.

accountsKeeper, err := NewKeeper(
in.Cdc, in.Environment, in.AddressCodec, in.Registry,
in.Cdc, in.Environment, in.AddressCodec, in.Registry, txDec,
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Codebase verification

Issues Found: Many NewKeeper calls across the codebase are missing the txDec parameter.
Please update all instances of NewKeeper to include the txDec parameter to ensure consistency and prevent potential issues.

🔗 Analysis chain

Verify that all calls to NewKeeper include the txDec parameter

To ensure consistency, please verify that all invocations of NewKeeper across the codebase have been updated to include the new txDec parameter.

Run the following script to check:

This script searches for all occurrences of NewKeeper and counts the number of arguments to ensure txDec is included.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all calls to `NewKeeper` include the `txDec` parameter.

# Test: Search for all invocations of `NewKeeper`. Expect: All calls should have five or more arguments before variadic parameters.

rg --type go 'NewKeeper\(' -A 5 | gawk '
BEGIN { FS="[\n()]" }
/NewKeeper\(/ { call=$0; getline; args=1; while ($0 !~ /\)/) { args++; getline; } if (args < 5) { print FILENAME ":" FNR ": " call " - missing txDec parameter"; } }
'

Length of output: 13040

Comment on lines +91 to +104
if m.k.bundlingDisabled {
return nil, ErrBundlingDisabled
}

_, err := m.k.addressCodec.StringToBytes(req.Bundler)
if err != nil {
return nil, err
}
responses := make([]*v1.BundledTxResponse, len(req.Txs))
for i, bundledTx := range req.Txs {
bundleRes := m.k.ExecuteBundledTx(ctx, req.Bundler, bundledTx)
responses[i] = bundleRes
}
return &v1.MsgExecuteBundleResponse{Responses: responses}, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Consider adding concurrency for executing bundled transactions.

To enhance performance, especially when dealing with a large number of transactions, consider processing the bundled transactions concurrently.

You might use goroutines and synchronization mechanisms to execute m.k.ExecuteBundledTx concurrently. Ensure that the underlying implementations are thread-safe and handle any potential concurrency issues, such as race conditions or shared resource conflicts.

Comment on lines +469 to +471
func (k *Keeper) DisableTxBundling() {
k.bundlingDisabled = true
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

⚠️ Potential issue

Potential Issue with DisableTxBundling Method

The DisableTxBundling method sets the bundlingDisabled flag to true:

func (k *Keeper) DisableTxBundling() {
    k.bundlingDisabled = true
}

However, if instances of Keeper are used with value receivers elsewhere, the state change may not persist as intended.

To ensure the bundlingDisabled state is correctly maintained:

  • Use pointer receivers consistently for all methods that modify the Keeper struct.
  • Ensure that Keeper instances are passed and stored as pointers where mutations are expected.

Consider updating the method and struct usage as follows:

-// Method with pointer receiver
 func (k *Keeper) DisableTxBundling() {
     k.bundlingDisabled = true
 }

-// Example of value receiver method
-func (k Keeper) SomeMethod() {
+// Update to pointer receiver
+func (k *Keeper) SomeMethod() {
     // method implementation
 }

And ensure that Keeper is used as a pointer throughout the codebase:

-keeper := Keeper{
+keeper := &Keeper{
     // struct initialization
 }

x/accounts/keeper.go Show resolved Hide resolved
Comment on lines +1837 to +1839
type _TxExtension_2_list struct {
list *[]*anypb.Any
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Avoid unnecessary use of pointer to slice in _TxExtension_2_list

In the _TxExtension_2_list struct, the list field is a pointer to a slice (*[]*anypb.Any). Since slices are already reference types in Go, using a pointer to a slice is generally unnecessary and can lead to complexity. Consider changing the field to a slice ([]*anypb.Any) instead.

Apply this diff to simplify the struct:

 type _TxExtension_2_list struct {
-	list *[]*anypb.Any
+	list []*anypb.Any
 }

Update the methods accordingly to accommodate this change. For example, modify the Len method:

 func (x *_TxExtension_2_list) Len() int {
-	if x.list == nil {
+	if x.list == nil {
 		return 0
 	}
-	return len(*x.list)
+	return len(x.list)
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
type _TxExtension_2_list struct {
list *[]*anypb.Any
}
type _TxExtension_2_list struct {
list []*anypb.Any
}

Comment on lines +2359 to 2360
list *[][]byte
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Type name _MsgExecuteBundle_2_list does not follow Go naming conventions

According to the Uber Go style guide, type names should be in PascalCase without underscores. Consider renaming _MsgExecuteBundle_2_list to MsgExecuteBundle2List to adhere to Go naming conventions and improve code readability.

v := new(v1beta11.TxRaw)
*x.list = append(*x.list, v)
return protoreflect.ValueOfMessage(v.ProtoReflect())
panic(fmt.Errorf("AppendMutable can not be called on message MsgExecuteBundle at list field Txs as it is not of Message kind"))
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

Avoid using panic in AppendMutable method

Per the Uber Go style guide, usage of panic is discouraged except for unrecoverable errors. Since AppendMutable should not be called for this type, consider returning an error or implementing a no-op to handle this case gracefully without panicking.

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 and nitpick comments (2)
x/accounts/README.md (2)

563-617: Comprehensive explanation of TxExtension

The Tx Extension section provides a detailed explanation of the TxExtension message and its fields. The protobuf definition and field explanations are clear and informative.

Consider revising the sentence on line 605 for better clarity:

- Can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.
+ It can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.
🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


618-638: Important compatibility considerations

This section provides crucial information about the compatibility of bundling with existing chain security measures. The instructions for disabling bundling are clear and helpful.

For consistency in the markdown style, consider changing the dash (-) to asterisks (*) in the unordered list:

- - Message validation
- - Admission control logic
+ * Message validation
+ * Admission control logic
🧰 Tools
🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between ad28604 and 7252890.

⛔ Files ignored due to path filters (1)
  • x/tx/go.sum is excluded by !**/*.sum
📒 Files selected for processing (2)
  • x/accounts/README.md (1 hunks)
  • x/tx/go.mod (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • x/tx/go.mod
🧰 Additional context used
📓 Path-based instructions (1)
x/accounts/README.md (1)

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

🪛 LanguageTool
x/accounts/README.md

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint
x/accounts/README.md

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

🔇 Additional comments (2)
x/accounts/README.md (2)

542-550: Well-written introduction to bundling

The introduction clearly explains the concept of transaction bundling and its advantages. It provides a good overview for developers who are new to this feature.


541-638: Excellent addition to the x/accounts documentation

The new content on transaction bundling is a valuable addition to the x/accounts README. It provides clear explanations of the bundling concept, its implementation details, and important compatibility considerations. The document is well-structured and informative, making it a useful resource for developers working with the x/accounts module.

🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

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: 1

🧹 Outside diff range and nitpick comments (7)
x/accounts/README.md (2)

563-617: Comprehensive explanation of TxExtension

The Tx Extension section provides a detailed and accurate explanation of the TxExtension message and its fields. The protobuf definition and field explanations are clear and informative.

Minor grammatical suggestion:

In line 605, consider adding "It" at the beginning of the sentence for better readability:

-Can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.
+It can be empty if payment arrangements are made off-chain or if the bundler doesn't require payment.
🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


618-638: Important compatibility considerations and clear instructions

The Compatibility section effectively highlights important considerations for chains implementing bundling and provides clear instructions on how to disable the feature if needed.

Minor formatting suggestion:

For consistency with Markdown formatting, consider changing the dash (-) to an asterisk (*) for the bullet points in lines 624-625:

-Message validation
-Admission control logic
+* Message validation
+* Admission control logic
🧰 Tools
🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

UPGRADING.md (5)

Line range hint 1-51: Significant new feature: Nested Messages Simulation in BaseApp

This new feature allows developers to simulate nested messages within transactions, providing a powerful tool for testing and predicting complex transaction behavior. Key points to note:

  1. It enables more comprehensive evaluation of gas consumption, state changes, and potential errors.
  2. The simulation doesn't guarantee correct execution in the future due to potential state changes.
  3. By default, gas cost of nested messages is not calculated in simulations.
  4. The SetIncludeNestedMsgsGas option allows customization of which message types should include nested message gas costs.

Developers should carefully consider implementing this feature to improve their transaction simulation accuracy, especially for complex governance proposals or other multi-message transactions.

Consider updating your application's BaseApp configuration to make use of this new feature, particularly for modules that frequently use nested messages.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


Line range hint 53-103: Important: Client package updates and address codec changes

The client package has been refactored to use address codecs and address bech32 prefixes. This change is part of abstracting the SDK from the global bech32 config. Key changes required:

  1. In the application client (usually root.go), update the client.Context to include address codecs and prefixes:

    clientCtx = clientCtx.
      WithAddressCodec(addressCodec).
      WithValidatorAddressCodec(validatorAddressCodec).
      WithConsensusAddressCodec(consensusAddressCodec).
      WithAddressPrefix("cosmos").
      WithValidatorPrefix("cosmosvaloper")
  2. Simplify the start command:

    - server.AddCommands(rootCmd, newApp, func(startCmd *cobra.Command) {})
    + server.AddCommands(rootCmd, newApp, server.StartCmdOptions[servertypes.Application]{})
  3. For depinject / app di users, these codecs can be provided directly from the application config.

Ensure that your application's client code is updated to include these changes, as they are crucial for proper address handling and command execution.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


Line range hint 105-185: Breaking change: gRPC Web removal and migration to Envoy proxy

The gRPC Web embedded client has been removed from the server. To continue using gRPC Web, you need to set up an Envoy proxy. Here's a summary of the required steps:

  1. Install Envoy following the official installation guide.
  2. Create an Envoy configuration file (envoy.yaml) with the provided configuration.
  3. Start your Cosmos SDK application, ensuring it's configured to serve gRPC on port 9090.
  4. Start Envoy with the configuration file: envoy -c envoy.yaml
  5. Update your client applications to connect to Envoy (http://localhost:8080 by default).

This change requires a significant update to your infrastructure setup. Consider the following:

  1. Update your deployment scripts or processes to include Envoy setup.
  2. Modify any client applications that were directly using the embedded gRPC Web to now connect through Envoy.
  3. Ensure your network configuration allows for the new Envoy proxy setup.

If you need help generating a custom Envoy configuration or updating your client applications, please let me know, and I can provide more detailed assistance.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


Line range hint 187-190: Important: AnteHandler changes

The GasConsumptionDecorator and IncreaseSequenceDecorator have been merged with the SigVerificationDecorator. This change requires updates to your app.go code:

Remove both GasConsumptionDecorator and IncreaseSequenceDecorator from your AnteHandler chain in app.go. Failure to do so will result in unresolvable symbols during compilation.

This simplification of the AnteHandler chain may impact gas consumption calculation and transaction sequence handling. Ensure that your application's transaction processing logic is updated accordingly.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


Line range hint 192-282: New feature: Unordered Transactions support

The Cosmos SDK now supports unordered transactions, allowing for more flexible transaction execution. Key points:

  1. Transactions can be executed in any order without client-side nonce management.
  2. Order of execution is not guaranteed.

Implementation instructions:

For depinject / app di users:

  • Supply the servertypes.AppOptions in app.go:
    depinject.Supply(
      appOpts,
      logger,
    )

For legacy wiring:

  1. Update the App constructor to create, load, and save the unordered transaction manager.
  2. Add the UnorderedTxDecorator to the AnteHandler chain.
  3. If using SnapshotManager, register the extension for the TxManager.
  4. Update or create the App's Preblocker() method.
  5. Update the App's Close() method to close the unordered tx manager.

This feature significantly changes how transactions are processed. Consider the following:

  1. Review your application's transaction processing logic to ensure compatibility with unordered transactions.
  2. Update any client-side code that relies on transaction ordering.
  3. Test thoroughly to ensure that critical operations are not affected by the lack of guaranteed execution order.

If you need help implementing unordered transactions in your application, especially for legacy wiring, please ask, and I can provide more detailed code examples.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 7252890 and 7603361.

📒 Files selected for processing (2)
  • UPGRADING.md (1 hunks)
  • x/accounts/README.md (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
UPGRADING.md (1)

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

x/accounts/README.md (1)

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

🪛 LanguageTool
UPGRADING.md

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

x/accounts/README.md

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint
UPGRADING.md

103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

x/accounts/README.md

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

🔇 Additional comments (4)
x/accounts/README.md (3)

542-550: Well-written introduction to transaction bundling

The introduction clearly explains the concept of transaction bundling and its advantages. It provides a good overview for developers and users to understand the feature's benefits.


551-561: Clear and informative diagram

The mermaid diagram effectively illustrates the transaction bundling process. It provides a visual representation that complements the textual explanation, enhancing understanding of the feature.


542-638: Excellent addition to the x/accounts documentation

The new sections on transaction bundling are a valuable addition to the x/accounts README. They provide comprehensive and clear explanations of the feature, its benefits, and important considerations for implementation. The mermaid diagram and protobuf definitions enhance the documentation's clarity. With the minor suggestions addressed, this update significantly improves the module's documentation.

🧰 Tools
🪛 LanguageTool

[style] ~605-~605: To form a complete sentence, be sure to include a subject.
Context: ...uding NFTs, IBC tokens, or delegations. Can be empty if payment arrangements are ma...

(MISSING_IT_THERE)

🪛 Markdownlint

624-624: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


625-625: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)


602-602: Expected: 1; Actual: 2; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


608-608: Expected: 1; Actual: 3; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)


613-613: Expected: 1; Actual: 4; Style: 1/1/1
Ordered list item prefix

(MD029, ol-prefix)

UPGRADING.md (1)

Line range hint 284-341: New feature: Sign Mode Textual

A new sign mode has been introduced to provide more human-readable output, currently available only on Ledger devices. Key points:

  1. This sign mode does not allow offline signing.
  2. It requires specific setup in both the application and client code.

Implementation instructions:

For legacy wiring:

  1. In app.go, after setting the app's bank keeper, add:

    enabledSignModes := append(tx.DefaultSignModes, sigtypes.SignMode_SIGN_MODE_TEXTUAL)
    txConfigOpts := tx.ConfigOptions{
      EnabledSignModes:           enabledSignModes,
      TextualCoinMetadataQueryFn: txmodule.NewBankKeeperCoinMetadataQueryFn(app.BankKeeper),
    }
    txConfig, err := tx.NewTxConfigWithOptions(
      appCodec,
      txConfigOpts,
    )
    if err != nil {
      log.Fatalf("Failed to create new TxConfig with options: %v", err)
    }
    app.txConfig = txConfig
  2. In the application client (usually root.go), add similar code but use NewGRPCCoinMetadataQueryFn instead.

For depinject / app di users:

  • It's enabled by default if there's a bank keeper present.
  • In the client, recreate the tx config from txConfigOpts to use NewGRPCCoinMetadataQueryFn.

When implementing this feature:

  1. Ensure that your application's signing process can handle this new mode.
  2. Update any client-side code that interacts with transaction signing to support this mode.
  3. Be aware of the limitation regarding offline signing and adjust your application's functionality accordingly.

After implementation, verify that:

  1. Ledger devices can correctly display and sign transactions using this new mode.
  2. Non-Ledger signing methods continue to work as expected.
  3. The application correctly handles both textual and non-textual signed transactions.
🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

104-104: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

UPGRADING.md Outdated
Comment on lines 88 to 103
##### TX Decoder

In order to support x/accounts properly we need to init a `TxDecoder`:

```diff
import (
+ txdecode "cosmossdk.io/x/tx/decode"
)
+ txDecoder, err := txdecode.NewDecoder(txdecode.Options{
+ SigningContext: signingCtx,
+ ProtoCodec: appCodec,
+ })
+ if err != nil {
+ panic(err)
+ }
```
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

Critical: TX Decoder initialization and Module Manager changes

Several important changes have been made to the application structure:

  1. TX Decoder initialization:

    • A new TxDecoder must be initialized to support x/accounts properly.
    • Add the following code to your app.go:
      txDecoder, err := txdecode.NewDecoder(txdecode.Options{
          SigningContext: signingCtx,
          ProtoCodec:     appCodec,
      })
      if err != nil {
          panic(err)
      }
  2. Module Manager simplification:

    • The basic module manager has been removed.
    • For depinject users, it's no longer necessary to supply a map[string]module.AppModuleBasic.
    • Custom parameters can be supplied directly.
  3. Module registration changes:

    • Call RegisterLegacyAminoCodec and RegisterInterfaces on the module manager instead of the basic module manager.

Update your application's app.go to incorporate these changes:

  1. Initialize the new TX Decoder.
  2. Remove references to the basic module manager.
  3. Update module registration calls to use the module manager directly.

These changes are crucial for proper functioning of your application with the new SDK version.

🧰 Tools
🪛 LanguageTool

[style] ~89-~89: Consider a shorter alternative to avoid wordiness.
Context: ...## Server (app.go) ##### TX Decoder In order to support x/accounts properly we need to ...

(IN_ORDER_TO_PREMIUM)


[uncategorized] ~90-~90: Possible missing comma found.
Context: ...Decoder In order to support x/accounts properly we need to init a TxDecoder: ```diff...

(AI_HYDRA_LEO_MISSING_COMMA)


[grammar] ~90-~90: Normally, after “need to” a verb is expected.
Context: ... to support x/accounts properly we need to init a TxDecoder: ```diff import ( + txd...

(WANT_TO_NN)

🪛 Markdownlint

103-103: null
Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

UPGRADING.md Outdated Show resolved Hide resolved
x/accounts/README.md Outdated Show resolved Hide resolved
x/accounts/msg_server.go Show resolved Hide resolved
Copy link
Member

@facundomedica facundomedica left a comment

Choose a reason for hiding this comment

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

LGTM, happy to have the bundler back :)

@@ -429,6 +466,10 @@ func (k Keeper) maybeSendFunds(ctx context.Context, from, to []byte, amt sdk.Coi
return nil
}

func (k *Keeper) DisableTxBundling() {
Copy link
Member

Choose a reason for hiding this comment

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

side question, will this be use for like gov in the future

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's commented in the docs, basically for some chains might be unsafe to run the bundler if they use Ante's to block msgs since the bundler can bypass.

@testinginprod testinginprod added this pull request to the merge queue Oct 25, 2024
Merged via the queue into main with commit ec63f94 Oct 25, 2024
74 of 75 checks passed
@testinginprod testinginprod deleted the tip/accounts/bundlers branch October 25, 2024 07:50
mergify bot pushed a commit that referenced this pull request Oct 25, 2024
(cherry picked from commit ec63f94)

# Conflicts:
#	api/cosmos/accounts/interfaces/account_abstraction/v1/interface.pulsar.go
#	api/cosmos/accounts/v1/tx.pulsar.go
#	x/accounts/README.md
#	x/accounts/go.mod
#	x/tx/go.mod
#	x/tx/go.sum
alpe added a commit that referenced this pull request Oct 25, 2024
* main: (157 commits)
  feat(core): add ConfigMap type (#22361)
  test: migrate e2e/genutil to systemtest (#22325)
  feat(accounts): re-introduce bundler (#21562)
  feat(log): add slog-backed Logger type (#22347)
  fix(x/tx): add feePayer as signer (#22311)
  test: migrate e2e/baseapp to integration tests (#22357)
  test: add x/circuit system tests (#22331)
  test: migrate e2e/tx tests to systemtest (#22152)
  refactor(simdv2): allow non-comet server components (#22351)
  build(deps): Bump rtCamp/action-slack-notify from 2.3.1 to 2.3.2 (#22352)
  fix(server/v2): respect context cancellation in start command (#22346)
  chore(simdv2): allow overriding the --home flag (#22348)
  feat(server/v2): add SimulateWithState to AppManager (#22335)
  docs(x/accounts): improve comments (#22339)
  chore: remove unused local variables (#22340)
  test: x/accounts systemtests (#22320)
  chore(client): use command's configured output (#22334)
  perf(log): use sonic json lib  (#22233)
  build(deps): bump x/tx (#22327)
  fix(x/accounts/lockup): fix proto path (#22319)
  ...
julienrbrt added a commit that referenced this pull request Oct 25, 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:x/accounts C:x/auth C:x/tx
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants