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(auth): allow BaseAccounts to be migrated to x/accounts #21820

Merged
merged 13 commits into from
Sep 23, 2024

Conversation

testinginprod
Copy link
Contributor

@testinginprod testinginprod commented Sep 19, 2024

Description

This PR allows for a way to explictly migrate BaseAccounts from x/auth to x/accounts, the choice of target account is left to the message sender.


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 account migration from legacy accounts to new account types using MsgMigrateAccount.
    • Added MsgInit message structure for account initialization, allowing optional sequence number adjustments.
    • New RPC method MigrateAccount added to facilitate account migrations.
    • Enhanced AccountsModKeeper interface with a method for migrating legacy accounts.
  • Bug Fixes

    • Updated account response structures for improved clarity and consistency.
  • Documentation

    • Updated comments and documentation for clarity regarding account structures and migration processes.

Copy link
Contributor

coderabbitai bot commented Sep 19, 2024

Walkthrough

Walkthrough

The pull request introduces a new account migration feature that enables users to migrate accounts from the x/auth module to the x/accounts module using the auth.MsgMigrateAccount message. This feature specifically targets BaseAccount types. Additionally, several modifications are made to related message structures, methods, and comments to support this migration functionality.

Changes

File Change Summary
UPGRADING.md Introduces account migration feature, detailing MsgMigrateAccount message structure and migration process.
api/cosmos/auth/v1beta1/accounts.pulsar.go Renames info field to base in QueryLegacyAccountResponse struct and updates related methods.
api/cosmos/auth/v1beta1/tx.pulsar.go Introduces MsgMigrateAccount and MsgMigrateAccountResponse message types with necessary methods.
x/auth/proto/cosmos/auth/v1beta1/accounts.proto Updates comment for base field in QueryLegacyAccountResponse.
x/auth/proto/cosmos/auth/v1beta1/tx.proto Adds MigrateAccount RPC method to the Msg service.
x/auth/types/expected_keepers.go Adds MigrateLegacyAccount method to AccountsModKeeper interface for handling legacy account migrations.

Possibly related PRs

  • feat(auth): support accounts from auth #21688: This PR introduces the MsgMigrateAccount message type, which is directly related to the account migration feature described in the main PR, as both involve migrating accounts and handling BaseAccount types.
  • docs(x/auth): vesting #21715: This PR discusses changes to account management, specifically the removal of vesting accounts and the introduction of x/accounts lockup accounts, which aligns with the migration process outlined in the main PR.

Suggested labels

Type: Build, Type: CI

Suggested reviewers

  • aaronc
  • facundomedica
  • sontrinh16
  • tac0turtle

Recent review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 4432b93 and b1f4dab.

Files ignored due to path filters (1)
  • x/auth/types/tx.pb.go is excluded by !**/*.pb.go
Files selected for processing (2)
  • api/cosmos/auth/v1beta1/tx.pulsar.go (5 hunks)
  • proto/cosmos/auth/v1beta1/tx.proto (2 hunks)
Files skipped from review as they are similar to previous changes (1)
  • proto/cosmos/auth/v1beta1/tx.proto
Additional context used
Path-based instructions (1)
api/cosmos/auth/v1beta1/tx.pulsar.go (1)

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

Additional comments not posted (3)
api/cosmos/auth/v1beta1/tx.pulsar.go (3)

2620-2620: Also applies to: 2622-2622, 3149-3149, 3151-3151


2426-2460: New message descriptors are correctly initialized

The message descriptors and field descriptors for MsgMigrateAccount are appropriately declared and initialized.


3638-3729: MsgMigrateAccount and MsgMigrateAccountResponse are properly defined

The new message types MsgMigrateAccount and MsgMigrateAccountResponse are well-defined with correct field types and tags. The associated methods implement the required interfaces.


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.

x.AccountInitMsg = value.Message().Interface().(*anypb.Any)
default:
if fd.IsExtension() {
panic(fmt.Errorf("proto3 declared messages do not support extensions: cosmos.auth.v1beta1.MsgMigrateAccount"))

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.auth.v1beta1.MsgMigrateAccount"))
}
panic(fmt.Errorf("message cosmos.auth.v1beta1.MsgMigrateAccount 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
x.InitResponse = value.Message().Interface().(*anypb.Any)
default:
if fd.IsExtension() {
panic(fmt.Errorf("proto3 declared messages do not support extensions: cosmos.auth.v1beta1.MsgMigrateAccountResponse"))

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.auth.v1beta1.MsgMigrateAccountResponse"))
}
panic(fmt.Errorf("message cosmos.auth.v1beta1.MsgMigrateAccountResponse 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
@@ -4,7 +4,14 @@
"context"
"errors"
"fmt"
"reflect"

Check notice

Code scanning / CodeQL

Sensitive package import Note

Certain system packages contain functions which may be a possible source of non-determinism
@testinginprod testinginprod marked this pull request as ready for review September 20, 2024 11:29

This comment has been minimized.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 11

Outside diff range and nitpick comments (2)
x/auth/types/expected_keepers.go (1)

35-41: LGTM! Consider adding documentation comments.

The MigrateLegacyAccount method signature looks good and follows the Golang naming conventions. The parameters are well-defined and serve the purpose of migrating legacy accounts to a new account type.

To improve the code readability and maintainability, consider adding documentation comments to explain the purpose of the method and its parameters. This will help future developers understand the functionality of the method at a glance.

UPGRADING.md (1)

979-984: Use consistent unordered list style.

For better readability, please use asterisks (*) consistently for the unordered list items in the example message structure, instead of dashes (-).

Tools
LanguageTool

[uncategorized] ~979-~979: Loose punctuation mark.
Context: ... ###### Field Descriptions -signer`: The address of the account you want to ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~980-~980: Loose punctuation mark.
Context: ...u want to migrate from. - account_type: The new account type you want to migrat...

(UNLIKELY_OPENING_PUNCTUATION)


[style] ~980-~980: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...account_type`: The new account type you want to migrate to (depends on what's installed...

(REP_WANT_TO_VB)


[uncategorized] ~981-~981: Loose punctuation mark.
Context: ...lled on the chain). - account_init_msg: The custom initialization message for t...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~982-~982: Loose punctuation mark.
Context: ...ssage for the new account. - @type: Specifies the type of account (in this ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~983-~983: Loose punctuation mark.
Context: .../accounts base account). - pub_key: The public key for the account. You can...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~984-~984: Loose punctuation mark.
Context: ...ic key if desired. - init_sequence: The new sequence number for the account...

(UNLIKELY_OPENING_PUNCTUATION)

Markdownlint

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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


984-984: 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 bdda21f and 5b02e74.

Files ignored due to path filters (4)
  • api/cosmos/auth/v1beta1/tx_grpc.pb.go is excluded by !**/*.pb.go
  • x/accounts/defaults/base/v1/base.pb.go is excluded by !**/*.pb.go
  • x/auth/types/accounts.pb.go is excluded by !**/*.pb.go
  • x/auth/types/tx.pb.go is excluded by !**/*.pb.go
Files selected for processing (16)
  • UPGRADING.md (1 hunks)
  • api/cosmos/accounts/defaults/base/v1/base.pulsar.go (14 hunks)
  • api/cosmos/auth/v1beta1/accounts.pulsar.go (16 hunks)
  • api/cosmos/auth/v1beta1/tx.pulsar.go (6 hunks)
  • tests/integration/auth/keeper/accounts_retro_compatibility_test.go (2 hunks)
  • tests/integration/auth/keeper/migrate_x_accounts_test.go (1 hunks)
  • x/accounts/defaults/base/account.go (4 hunks)
  • x/accounts/proto/cosmos/accounts/defaults/base/v1/base.proto (1 hunks)
  • x/auth/CHANGELOG.md (1 hunks)
  • x/auth/keeper/grpc_query.go (1 hunks)
  • x/auth/keeper/msg_server.go (2 hunks)
  • x/auth/proto/cosmos/auth/v1beta1/accounts.proto (1 hunks)
  • x/auth/proto/cosmos/auth/v1beta1/tx.proto (2 hunks)
  • x/auth/testutil/expected_keepers_mocks.go (1 hunks)
  • x/auth/types/codec.go (1 hunks)
  • x/auth/types/expected_keepers.go (1 hunks)
Files skipped from review due to trivial changes (1)
  • x/auth/proto/cosmos/auth/v1beta1/accounts.proto
Additional context used
Path-based instructions (13)
UPGRADING.md (1)

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

api/cosmos/accounts/defaults/base/v1/base.pulsar.go (1)

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

api/cosmos/auth/v1beta1/accounts.pulsar.go (1)

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

api/cosmos/auth/v1beta1/tx.pulsar.go (1)

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

tests/integration/auth/keeper/accounts_retro_compatibility_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/migrate_x_accounts_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/defaults/base/account.go (1)

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

x/auth/CHANGELOG.md (1)

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

x/auth/keeper/grpc_query.go (1)

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

x/auth/keeper/msg_server.go (1)

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

x/auth/testutil/expected_keepers_mocks.go (1)

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

x/auth/types/codec.go (1)

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

x/auth/types/expected_keepers.go (1)

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

LanguageTool
UPGRADING.md

[uncategorized] ~979-~979: Loose punctuation mark.
Context: ... ###### Field Descriptions -signer`: The address of the account you want to ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~980-~980: Loose punctuation mark.
Context: ...u want to migrate from. - account_type: The new account type you want to migrat...

(UNLIKELY_OPENING_PUNCTUATION)


[style] ~980-~980: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...account_type`: The new account type you want to migrate to (depends on what's installed...

(REP_WANT_TO_VB)


[uncategorized] ~981-~981: Loose punctuation mark.
Context: ...lled on the chain). - account_init_msg: The custom initialization message for t...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~982-~982: Loose punctuation mark.
Context: ...ssage for the new account. - @type: Specifies the type of account (in this ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~983-~983: Loose punctuation mark.
Context: .../accounts base account). - pub_key: The public key for the account. You can...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~984-~984: Loose punctuation mark.
Context: ...ic key if desired. - init_sequence: The new sequence number for the account...

(UNLIKELY_OPENING_PUNCTUATION)

Markdownlint
UPGRADING.md

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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)

x/auth/CHANGELOG.md

64-64: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)

Additional comments not posted (36)
x/accounts/proto/cosmos/accounts/defaults/base/v1/base.proto (1)

13-14: LGTM!

The addition of the init_sequence field to the MsgInit message is a valuable enhancement. It provides the flexibility to set a custom initial sequence during account initialization.

Key points:

  • The field type uint64 is appropriate for representing the sequence number.
  • The field number 2 follows the correct sequential ordering.
  • The comment accurately describes the purpose of the field.
  • This is a non-breaking change, maintaining backward compatibility for existing clients.

Well done!

x/auth/types/codec.go (1)

62-62: LGTM!

The registration of &MsgMigrateAccount{} as an implementation of coretransaction.Msg interface is consistent with the existing code pattern and follows the Uber Golang style guide.

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

44-52: LGTM!

The subtest correctly verifies the behavior when the account to be migrated does not exist. It checks that the response is nil and the error is sdkerrors.ErrUnknownAddress.


54-62: LGTM!

The subtest correctly verifies the behavior when the account type is invalid for migration. It checks that the response is nil and the error contains "only BaseAccount can be migrated".


64-99: LGTM!

The subtest correctly verifies the successful migration of a base account. It checks the following:

  • The response has the expected type URL and non-nil value.
  • The account is removed from the auth keeper and added to the accounts keeper.
  • The sequence and public key in the accounts keeper match the init message.
x/auth/keeper/msg_server.go (3)

7-13: Imports look good, but use "reflect" sparingly.

The newly added imports are relevant and justified based on the codebase's apparent use of protocol buffers and gRPC. However, be cautious with the "reflect" package as it can make the code harder to understand and maintain if overused. Use it only when absolutely necessary.


79-116: LGTM!

The MigrateAccount method is well-structured and follows a clear sequence of steps to handle the account migration process. It performs necessary checks and validations, handles errors appropriately, and updates the state correctly after a successful migration. The logic aligns with the expected behavior and the code is readable and maintainable.


118-135: The unpackAnyRaw function looks good, but be mindful of the reflection trade-off.

The unpackAnyRaw function correctly handles the unpacking of codectypes.Any messages into concrete message types using reflection. It follows a clear sequence of steps and handles errors appropriately. The use of reflection allows for flexibility in handling different message types, but it comes at the cost of making the code harder to understand and maintain. Be mindful of this trade-off and ensure that the flexibility provided by reflection is necessary and justified in this case.

tests/integration/auth/keeper/accounts_retro_compatibility_test.go (2)

Line range hint 49-54: LGTM!

The field renaming from Info to Base in the authtypes.QueryLegacyAccountResponse structure is consistent with the updated data model. The code changes look good.


89-89: LGTM!

The assertion update to compare infoResp.Info with valid.retroCompat.Base is consistent with the field renaming in the authtypes.QueryLegacyAccountResponse structure. The code changes look good.

x/auth/CHANGELOG.md (2)

64-64: LGTM!

The changelog entry accurately describes the new account migration feature and follows the proper format. Great job!

Tools
Markdownlint

64-64: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)


64-64: Skipping Markdownlint suggestion.

The changelog follows a specific format and structure. Surrounding lists with blank lines, while a general Markdown best practice, may not be applicable or necessary here. Applying the suggestion could negatively impact the readability and consistency of the changelog.

Tools
Markdownlint

64-64: null
Lists should be surrounded by blank lines

(MD032, blanks-around-lists)

x/auth/testutil/expected_keepers_mocks.go (2)

137-144: LGTM!

The MigrateLegacyAccount method is correctly added to the MockAccountsModKeeper struct to mock the base method for migrating legacy accounts. The function signature matches the expected signature and the mock implementation using gomock is correct.


146-150: LGTM!

The MigrateLegacyAccount recorder method is correctly added to the MockAccountsModKeeperMockRecorder struct. It matches the signature of the mocked method and correctly records the expected call using gomock.

x/auth/keeper/grpc_query.go (1)

234-234: LGTM!

The changes in the error handling logic for accounts fetched from the x/accounts module are correct. The shift from checking xAccount.Info to xAccount.Base aligns with the updated data structure used to represent account information in the x/accounts module.

Also applies to: 237-237

x/accounts/defaults/base/account.go (4)

73-78: LGTM!

The changes to the Init method look good. The conditional check ensures that the sequence is only set if msg.InitSequence is non-zero, and proper error handling is in place.


267-277: LGTM!

The new QueryPubKey method looks good. It follows a clear sequence of steps to load the public key, wrap it in an Any type, and return it in the response. Proper error handling is in place.


317-317: LGTM!

The renaming of the field from Info to Base in the QueryLegacyAccountResponse struct improves consistency with the naming convention used in the codebase. The change does not impact the functionality of the AuthRetroCompatibility method.


332-332: LGTM!

The registration of the QueryPubKey method in the RegisterQueryHandlers method is necessary to make the new query handler accessible. The registration follows the same pattern as the existing query handlers.

api/cosmos/auth/v1beta1/accounts.pulsar.go (2)

375-375: LGTM!

The renaming of the Info field to Base in the QueryLegacyAccountResponse struct is consistently applied across the file. The comments have been updated accurately to reflect the new field name.

Also applies to: 382-382, 456-458, 479-480, 499-500, 520-521, 593-593, 940-943, 973-975, 996-999, 1037-1037


Line range hint 1-1:

api/cosmos/accounts/defaults/base/v1/base.pulsar.go (14)

17-19: Addition of 'InitSequence' Field Descriptor

The field descriptor fd_MsgInit_init_sequence is correctly added to support the new InitSequence field in the MsgInit message.


26-26: Initialization of 'fd_MsgInit_init_sequence'

Properly initializes fd_MsgInit_init_sequence by retrieving the init_sequence field from md_MsgInit.


100-105: Update 'Range' Method to Include 'InitSequence'

The Range method now correctly iterates over InitSequence when it is non-zero, ensuring the field is included during reflection.


123-124: Update 'Has' Method for 'InitSequence'

The Has method appropriately checks if InitSequence is populated by verifying it is not equal to zero.


143-144: Update 'Clear' Method for 'InitSequence'

The Clear method correctly resets InitSequence to its zero value, effectively clearing the field.


164-166: Update 'Get' Method for 'InitSequence'

The Get method properly retrieves the value of InitSequence and returns it as a protoreflect.Value.


189-190: Update 'Set' Method for 'InitSequence'

The Set method correctly assigns a new value to InitSequence from the provided protoreflect.Value.


216-217: Handling 'Mutable' Method for Non-Mutable Field 'InitSequence'

Attempting to call Mutable on InitSequence correctly results in a panic, as scalar fields are not mutable. This behavior is consistent with the handling of non-mutable fields in the codebase.


234-235: Update 'NewField' Method for 'InitSequence'

The NewField method appropriately returns a default value for InitSequence, aligning with the expected behavior for scalar fields.


309-311: Update 'size' Function in 'ProtoMethods' to Account for 'InitSequence'

The size calculation now includes InitSequence when it is set, ensuring accurate size determination during serialization.


341-345: Update 'marshal' Function in 'ProtoMethods' for 'InitSequence'

The marshal function correctly handles serialization of InitSequence, writing it to the byte buffer when it is non-zero.


445-463: Update 'unmarshal' Function in 'ProtoMethods' for 'InitSequence'

The unmarshal function properly deserializes InitSequence from the input buffer, correctly interpreting the wire type and field number.


3218-3219: Addition of 'InitSequence' Field to 'MsgInit' Struct

The InitSequence field is added to the MsgInit struct with the correct protobuf tags, enabling serialization and deserialization.


3249-3255: Implementation of 'GetInitSequence' Method

The getter method for InitSequence is accurately implemented, providing safe access to the field's value.

api/cosmos/auth/v1beta1/tx.pulsar.go (1)

2426-3423: LGTM: Implementation of MsgMigrateAccount and MsgMigrateAccountResponse

The new message types MsgMigrateAccount and MsgMigrateAccountResponse, along with their associated reflection methods, are correctly implemented and conform to the Go and protobuf conventions.

option (cosmos.msg.v1.signer) = "signer";

string signer = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
string account_type = 2;
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider using an enumeration for the account_type field

Instead of using a string for account_type, consider defining an enum to enforce valid account types and prevent invalid values. This enhances type safety and makes the code more robust.

Example:

enum AccountType {
  UNKNOWN = 0;
  MODULE_ACCOUNT = 1;
  CUSTOM_ACCOUNT = 2;
  // Add other account types as needed.
}

...

AccountType account_type = 2;

Comment on lines 84 to 85
// init_response defines the response returned by the x/account account
// initialization.
Copy link
Contributor

Choose a reason for hiding this comment

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

Improve the description of init_response field

Clarify the comment for the init_response field to provide better understanding of its contents.

Apply this diff:

 // init_response defines the response returned by the x/account account
-// initialization.
+// initialization, containing any data returned by the initialization process of the new account type.
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
// init_response defines the response returned by the x/account account
// initialization.
// init_response defines the response returned by the x/account account
// initialization, containing any data returned by the initialization process of the new account type.

Comment on lines 71 to 72
// MsgMigrateAccount defines a message which allows users to migrate from BaseAccount
// to other x/accounts types.
Copy link
Contributor

Choose a reason for hiding this comment

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

Clarify the description of MsgMigrateAccount

To improve clarity, rephrase the comment describing MsgMigrateAccount to better convey its functionality.

Apply this diff:

 // MsgMigrateAccount defines a message which allows users to migrate from BaseAccount
-// to other x/accounts types.
+// to other account types in the `x/accounts` module.
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
// MsgMigrateAccount defines a message which allows users to migrate from BaseAccount
// to other x/accounts types.
// MsgMigrateAccount defines a message which allows users to migrate from BaseAccount
// to other account types in the `x/accounts` module.


string signer = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
string account_type = 2;
google.protobuf.Any account_init_msg = 3;
Copy link
Contributor

Choose a reason for hiding this comment

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

Specify accepted interface for account_init_msg field

To ensure type safety and clarity, please specify the (cosmos_proto.accepts_interface) option for the account_init_msg field, indicating the expected interface that the initialization message should implement.

Apply this diff:

 google.protobuf.Any account_init_msg = 3
+  [(cosmos_proto.accepts_interface) = "cosmos.accounts.v1beta1.AccountInitMsg"];
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
google.protobuf.Any account_init_msg = 3;
google.protobuf.Any account_init_msg = 3
[(cosmos_proto.accepts_interface) = "cosmos.accounts.v1beta1.AccountInitMsg"];

@@ -22,6 +22,9 @@

// NonAtomicExec allows users to submit multiple messages for non-atomic execution.
rpc NonAtomicExec(MsgNonAtomicExec) returns (MsgNonAtomicExecResponse);

// MigrateAccount migrates the account to x/accounts.
Copy link
Contributor

Choose a reason for hiding this comment

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

Enhance the documentation of the MigrateAccount RPC method

Consider providing a more detailed comment for the MigrateAccount method to clearly explain its purpose and usage, helping developers understand how to utilize this new functionality.

Apply this diff:

 // MigrateAccount migrates the account to x/accounts.
+ // Allows a user to migrate their account from `x/auth` to the `x/accounts` module,
+ // enabling them to switch to a different account type with extended functionalities.
 rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);
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
// MigrateAccount migrates the account to x/accounts.
// MigrateAccount migrates the account to x/accounts.
// Allows a user to migrate their account from `x/auth` to the `x/accounts` module,
// enabling them to switch to a different account type with extended functionalities.
rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);

Comment on lines 83 to 84
message MsgMigrateAccountResponse {
// init_response defines the response returned by the x/account account
Copy link
Contributor

Choose a reason for hiding this comment

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

Add amino.name option to MsgMigrateAccountResponse

Including the option (amino.name) in MsgMigrateAccountResponse ensures consistency and supports Amino serialization.

Apply this diff:

 message MsgMigrateAccountResponse {
+  option (amino.name) = "cosmos-sdk/MsgMigrateAccountResponse";
   // init_response defines the response returned by the x/account account
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
message MsgMigrateAccountResponse {
// init_response defines the response returned by the x/account account
message MsgMigrateAccountResponse {
option (amino.name) = "cosmos-sdk/MsgMigrateAccountResponse";
// init_response defines the response returned by the x/account account

Add message_added_in option to MsgMigrateAccountResponse message

For completeness and to aid documentation, add the option (cosmos_proto.message_added_in) to the MsgMigrateAccountResponse message.

Apply this diff:

 message MsgMigrateAccountResponse {
+  option (cosmos_proto.message_added_in) = "cosmos-sdk 0.51";
   // init_response defines the response returned by the x/account account
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
message MsgMigrateAccountResponse {
// init_response defines the response returned by the x/account account
message MsgMigrateAccountResponse {
option (cosmos_proto.message_added_in) = "cosmos-sdk 0.51";
// init_response defines the response returned by the x/account account

message MsgMigrateAccountResponse {
// init_response defines the response returned by the x/account account
// initialization.
google.protobuf.Any init_response = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Specify accepted interface for init_response field

Similarly, add the (cosmos_proto.accepts_interface) option to the init_response field to indicate the expected interface of the initialization response.

Apply this diff:

 google.protobuf.Any init_response = 1;
+  [(cosmos_proto.accepts_interface) = "cosmos.accounts.v1beta1.AccountInitResponse"];
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
google.protobuf.Any init_response = 1;
google.protobuf.Any init_response = 1
[(cosmos_proto.accepts_interface) = "cosmos.accounts.v1beta1.AccountInitResponse"];

Comment on lines 73 to 74
message MsgMigrateAccount {
option (cosmos.msg.v1.signer) = "signer";
Copy link
Contributor

Choose a reason for hiding this comment

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

Add amino.name option to MsgMigrateAccount

To ensure compatibility with Amino serialization, consider adding the option (amino.name) to MsgMigrateAccount, following the pattern used in other messages.

Apply this diff:

 message MsgMigrateAccount {
   option (cosmos.msg.v1.signer) = "signer";
+  option (amino.name) = "cosmos-sdk/MsgMigrateAccount";
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
message MsgMigrateAccount {
option (cosmos.msg.v1.signer) = "signer";
message MsgMigrateAccount {
option (cosmos.msg.v1.signer) = "signer";
option (amino.name) = "cosmos-sdk/MsgMigrateAccount";

Add message_added_in option to MsgMigrateAccount message

Please include the option (cosmos_proto.message_added_in) in the MsgMigrateAccount message to indicate the version it was added, ensuring consistency across messages.

Apply this diff:

 message MsgMigrateAccount {
+  option (cosmos_proto.message_added_in) = "cosmos-sdk 0.51";
   option (cosmos.msg.v1.signer) = "signer";
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
message MsgMigrateAccount {
option (cosmos.msg.v1.signer) = "signer";
message MsgMigrateAccount {
option (cosmos_proto.message_added_in) = "cosmos-sdk 0.51";
option (cosmos.msg.v1.signer) = "signer";

Comment on lines 26 to 27
// MigrateAccount migrates the account to x/accounts.
rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);
Copy link
Contributor

Choose a reason for hiding this comment

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

Add method_added_in option to MigrateAccount RPC method

To maintain consistency and aid in version tracking, please add the option (cosmos_proto.method_added_in) to the MigrateAccount RPC method, specifying the version in which it was introduced, similar to the UpdateParams method.

Apply this diff:

 rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);
+ {
+   option (cosmos_proto.method_added_in) = "cosmos-sdk 0.51";
+ }
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
// MigrateAccount migrates the account to x/accounts.
rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);
// MigrateAccount migrates the account to x/accounts.
rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse) {
option (cosmos_proto.method_added_in) = "cosmos-sdk 0.51";
}

# Conflicts:
#	api/cosmos/auth/v1beta1/accounts.pulsar.go
#	x/auth/types/accounts.pb.go
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

Outside diff range and nitpick comments (4)
proto/cosmos/auth/v1beta1/tx.proto (1)

26-27: LGTM! Consider adding signer option.

The new RPC method MigrateAccount is well-placed and correctly defined. It aligns with the feature description for migrating accounts.

Consider adding the option (cosmos.msg.v1.signer) to the RPC method for consistency with other methods in the service:

 rpc MigrateAccount(MsgMigrateAccount) returns (MsgMigrateAccountResponse);
+  option (cosmos.msg.v1.signer) = "signer";
UPGRADING.md (3)

949-950: Improve section header formatting

The section header for the account migration guide should be formatted as a proper Markdown header for better readability and structure.

Consider changing the header to:

-#### Account Migration Guide: x/auth to x/accounts
+### Account Migration Guide: x/auth to x/accounts

958-968: Improve formatting and clarity of migration process explanation

The explanation of the migration process could be formatted better for improved readability. Additionally, some clarifications could be added to make the process more understandable.

Consider the following improvements:

  1. Use proper Markdown formatting for headers and lists.
  2. Clarify the relationship between auth.MsgMigrateAccount and basev1.MsgInit.
  3. Explain why users might want to switch to a new public key or reset their sequence number.

Here's a suggested revision:

### Migration Process

The migration process allows users to migrate from a legacy `x/auth` `BaseAccount` to any kind of `x/accounts` supported account type. Here's how to migrate to an `x/accounts` `BaseAccount`:

1. Send an `auth.MsgMigrateAccount` message.
2. Within this message, include a `basev1.MsgInit` message, which allows you to:
   - Switch to a new public key (optional)
   - Reset your sequence number (optional)

> **Important**: If you intend to keep the same public key, ensure you use your current sequence number to prevent potential replay attacks.
Tools
Markdownlint

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

(MD004, ul-style)


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

(MD004, ul-style)


987-997: Improve field descriptions formatting and clarity

The field descriptions could be formatted better for improved readability. Some additional explanations could also be helpful.

Consider the following improvements:

  1. Use proper Markdown formatting for the list.
  2. Provide more context for the account_type field.
  3. Clarify the purpose and importance of the init_sequence field.

Here's a suggested revision:

### Field Descriptions

* `signer`: The address of the account you want to migrate from.
* `account_type`: The new account type you want to migrate to. This depends on what account types are installed on the chain. In this example, it's set to "base" for a base account.
* `account_init_msg`: The custom initialization message for the new account.
  - `@type`: Specifies the type of account (in this case, x/accounts base account).
  - `pub_key`: The public key for the account. You can migrate to a different public key if desired.
  - `init_sequence`: The new sequence number for the account. This is crucial for preventing replay attacks. If you're keeping the same public key, use your current sequence number.

> **Warning**: If you're keeping the same public key, make sure to use your current sequence number to prevent potential replay attacks.
Tools
LanguageTool

[uncategorized] ~989-~989: Loose punctuation mark.
Context: ... ###### Field Descriptions -signer`: The address of the account you want to ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~990-~990: Loose punctuation mark.
Context: ...u want to migrate from. - account_type: The new account type you want to migrat...

(UNLIKELY_OPENING_PUNCTUATION)


[style] ~990-~990: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...account_type`: The new account type you want to migrate to (depends on what's installed...

(REP_WANT_TO_VB)


[uncategorized] ~991-~991: Loose punctuation mark.
Context: ...lled on the chain). - account_init_msg: The custom initialization message for t...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~992-~992: Loose punctuation mark.
Context: ...ssage for the new account. - @type: Specifies the type of account (in this ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~993-~993: Loose punctuation mark.
Context: .../accounts base account). - pub_key: The public key for the account. You can...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~994-~994: Loose punctuation mark.
Context: ...ic key if desired. - init_sequence: The new sequence number for the account...

(UNLIKELY_OPENING_PUNCTUATION)

Markdownlint

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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


994-994: 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 5b02e74 and fbec402.

Files selected for processing (3)
  • UPGRADING.md (1 hunks)
  • proto/cosmos/auth/v1beta1/accounts.proto (1 hunks)
  • proto/cosmos/auth/v1beta1/tx.proto (2 hunks)
Files skipped from review due to trivial changes (1)
  • proto/cosmos/auth/v1beta1/accounts.proto
Additional context used
Path-based instructions (1)
UPGRADING.md (1)

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

LanguageTool
UPGRADING.md

[uncategorized] ~989-~989: Loose punctuation mark.
Context: ... ###### Field Descriptions -signer`: The address of the account you want to ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~990-~990: Loose punctuation mark.
Context: ...u want to migrate from. - account_type: The new account type you want to migrat...

(UNLIKELY_OPENING_PUNCTUATION)


[style] ~990-~990: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...account_type`: The new account type you want to migrate to (depends on what's installed...

(REP_WANT_TO_VB)


[uncategorized] ~991-~991: Loose punctuation mark.
Context: ...lled on the chain). - account_init_msg: The custom initialization message for t...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~992-~992: Loose punctuation mark.
Context: ...ssage for the new account. - @type: Specifies the type of account (in this ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~993-~993: Loose punctuation mark.
Context: .../accounts base account). - pub_key: The public key for the account. You can...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~994-~994: Loose punctuation mark.
Context: ...ic key if desired. - init_sequence: The new sequence number for the account...

(UNLIKELY_OPENING_PUNCTUATION)

Markdownlint
UPGRADING.md

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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)

Additional comments not posted (5)
proto/cosmos/auth/v1beta1/tx.proto (3)

71-79: LGTM! Well-structured message definition.

The MsgMigrateAccount message is well-defined and includes all necessary fields for the account migration feature. The use of google.protobuf.Any for account_init_msg provides the required flexibility for different account types.


81-87: LGTM! Clear and flexible response message.

The MsgMigrateAccountResponse message is well-defined. The use of google.protobuf.Any for init_response allows for flexible response types from different account initializations.


Line range hint 25-87: Overall, the changes effectively implement the account migration feature.

The additions to this file (new RPC method and message types) are well-structured and consistent with the PR objectives. They provide the necessary flexibility for migrating different account types while maintaining a clear and logical structure.

Key points:

  1. The new MigrateAccount RPC method is appropriately placed in the Msg service.
  2. MsgMigrateAccount includes all necessary fields for initiating a migration.
  3. MsgMigrateAccountResponse allows for flexible responses from different account initializations.

These changes lay a solid foundation for the account migration feature in the Cosmos SDK.

UPGRADING.md (2)

951-957: LGTM: Clear introduction to account migration

The introduction provides a concise explanation of the new account migration feature and its current limitations. This is helpful for users to understand the scope of the migration process.


969-986: LGTM: Clear example of x/auth.MsgMigrateAccount

The provided example of the x/auth.MsgMigrateAccount message structure is clear and helpful. It demonstrates the correct format and includes all necessary fields.

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

@julienrbrt julienrbrt left a comment

Choose a reason for hiding this comment

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

lgtm! only nits about docs

@@ -59,5 +59,6 @@ func RegisterInterfaces(registrar registry.InterfaceRegistrar) {
registrar.RegisterImplementations((*coretransaction.Msg)(nil),
&MsgUpdateParams{},
&MsgNonAtomicExec{},
&MsgMigrateAccount{},
Copy link
Member

Choose a reason for hiding this comment

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

we should register it on amino above I think

x/auth/types/expected_keepers.go Show resolved Hide resolved
UPGRADING.md Outdated Show resolved Hide resolved
Copy link
Contributor

@akhilkumarpilli akhilkumarpilli left a comment

Choose a reason for hiding this comment

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

lgtm

UPGRADING.md Outdated Show resolved Hide resolved
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

Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between fbec402 and c9d44c2.

Files selected for processing (1)
  • UPGRADING.md (1 hunks)
Additional context used
Path-based instructions (1)
UPGRADING.md (1)

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

LanguageTool
UPGRADING.md

[uncategorized] ~989-~989: Loose punctuation mark.
Context: ... ``` Field Descriptions - signer: The address of the account you want to ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~990-~990: Loose punctuation mark.
Context: ...u want to migrate from. - account_type: The new account type you want to migrat...

(UNLIKELY_OPENING_PUNCTUATION)


[style] ~990-~990: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...account_type`: The new account type you want to migrate to (depends on what's installed...

(REP_WANT_TO_VB)


[uncategorized] ~991-~991: Loose punctuation mark.
Context: ...lled on the chain). - account_init_msg: The custom initialization message for t...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~992-~992: Loose punctuation mark.
Context: ...ssage for the new account. - @type: Specifies the type of account (in this ...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~993-~993: Loose punctuation mark.
Context: .../accounts base account). - pub_key: The public key for the account. You can...

(UNLIKELY_OPENING_PUNCTUATION)


[uncategorized] ~994-~994: Loose punctuation mark.
Context: ...ic key if desired. - init_sequence: The new sequence number for the account...

(UNLIKELY_OPENING_PUNCTUATION)

Markdownlint
UPGRADING.md

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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


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

(MD004, ul-style)


987-987: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

UPGRADING.md Show resolved Hide resolved
@testinginprod testinginprod added this pull request to the merge queue Sep 23, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 23, 2024
@testinginprod testinginprod added this pull request to the merge queue Sep 23, 2024
Merged via the queue into main with commit ebbaa0e Sep 23, 2024
73 of 75 checks passed
@testinginprod testinginprod deleted the tip/auth/migrate_to_accounts branch September 23, 2024 21:27
mergify bot pushed a commit that referenced this pull request Sep 23, 2024
Co-authored-by: Akhil Kumar P <[email protected]>
(cherry picked from commit ebbaa0e)

# Conflicts:
#	UPGRADING.md
#	api/cosmos/accounts/defaults/base/v1/base.pulsar.go
#	api/cosmos/auth/v1beta1/accounts.pulsar.go
#	api/cosmos/auth/v1beta1/tx.pulsar.go
#	api/cosmos/auth/v1beta1/tx_grpc.pb.go
julienrbrt added a commit that referenced this pull request Sep 24, 2024
@julienrbrt julienrbrt mentioned this pull request Sep 24, 2024
10 tasks
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/base C:x/accounts C:x/auth
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants