feat(client/v2): factory and txBuilder #20623
Conversation
|
Note Reviews pausedUse the following commands to manage reviews:
WalkthroughWalkthroughThe recent changes enhance the client functionality of a Cosmos SDK-based application. Key modifications include the integration of address codecs into keyring management, the addition of methods for retrieving key type and information, and improvements in transaction handling with new utilities for account and coin operations. The changes also introduce tests to validate these functionalities, and the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Keyring
participant TxFactory
participant Network
User->>CLI: Request to build transaction
CLI->>Keyring: Initialize keyring with address codec
Keyring-->>CLI: Keyring instance
CLI->>TxFactory: Prepare transaction
TxFactory->>Network: Retrieve account info
Network-->>TxFactory: Account details
TxFactory->>CLI: Unsigned transaction
CLI->>Keyring: Sign transaction
Keyring-->>CLI: Signed transaction
CLI->>Network: Broadcast transaction
Network-->>CLI: Transaction response
CLI-->>User: Response details
Possibly related PRs
Suggested labels
Suggested reviewers
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? TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
remove factory withs, parsing gas and fees,
JulianToledano
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
Outside diff range and nitpick comments (2)
client/v2/tx/aux_builder_test.go (1)
34-226: Comprehensive testing ofAuxTxBuilderfunctionalities.The test cases in
TestAuxTxBuilderare comprehensive, covering various error scenarios and successful setups. The use of table-driven tests enhances the maintainability and readability of the tests. However, consider adding a few more comments within the test cases to explain the rationale behind specific checks, especially for complex scenarios.+ // Test case: "cannot set SIGN_MODE_DIRECT" checks that only specific signing modes are allowed + // Test case: "GetSignBytes body should not be nil" ensures that the builder is properly initialized before useclient/v2/tx/tx.go (1)
102-123: Ensure consistency in error messages.The
validatefunction uses different styles for error messages. Consistency in error messages improves readability and maintainability. Consider using a consistent format for all error messages within this function.- return errors.New("account-number and sequence must be set in offline mode") + return errors.New("account-number and sequence must be set in offline mode.") - return errors.New("chain ID cannot be used when offline and generate-only flags are set") + return errors.New("chain ID cannot be used when offline and generate-only flags are set.") - return errors.New("chain ID required but not specified") + return errors.New("chain ID is required but not specified.")
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (11)
- client/v2/tx/README.md (1 hunks)
- client/v2/tx/aux_builder_test.go (1 hunks)
- client/v2/tx/builder.go (1 hunks)
- client/v2/tx/builder_test.go (1 hunks)
- client/v2/tx/config.go (1 hunks)
- client/v2/tx/encoder.go (1 hunks)
- client/v2/tx/encoder_test.go (1 hunks)
- client/v2/tx/factory.go (1 hunks)
- client/v2/tx/tx.go (1 hunks)
- client/v2/tx/types.go (1 hunks)
- client/v2/tx/wrapper.go (1 hunks)
Additional context used
Path-based instructions (11)
client/v2/tx/encoder_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"client/v2/tx/wrapper.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/encoder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/types.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/aux_builder_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"client/v2/tx/builder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/config.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/tx.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/builder_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"client/v2/tx/factory.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/README.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
LanguageTool
client/v2/tx/README.md
[grammar] ~512-~512: The verb ‘Prepare’ does not usually follow articles like ‘a’. Check that ‘Prepare’ is spelled correctly; using ‘Prepare’ as a noun may be non-standard.
Context: ...ackage, typically you would: 1. Create aFactory2. Prepare the account 3. Build an unsigned transa...(A_INFINITIVE)
Additional comments not posted (51)
client/v2/tx/encoder_test.go (3)
16-49: Helper functiongetWrappedTxlooks good.The helper function correctly sets up a wrapped transaction for testing.
51-74: Test functionTest_txEncoder_txDecoderlooks good.The test function correctly verifies the encoding and decoding process, including checks for determinism and equality.
76-104: Test functionTest_txJsonEncoder_txJsonDecoderlooks good.The test function correctly verifies the JSON encoding and decoding process, including checks for equality.
client/v2/tx/wrapper.go (5)
30-35: Initialization methodnewWrapperTxlooks good.The method correctly initializes the
wrappedTxstruct with the provided codec and decoded transaction.
37-40: MethodGetSignerslooks good.The method correctly returns the signers from the decoded transaction.
42-65: MethodGetPubKeyslooks good.The method correctly retrieves and decodes the public keys from the transaction's SignerInfos, including error handling for invalid public key types.
67-97: MethodGetSignatureslooks good.The method correctly retrieves the signatures and constructs the Signature structs, including error handling for invalid signature data.
99-115: MethoddecodeAnylooks good.The method correctly decodes the Any message using reflection and the provided codec, including error handling for unknown types and unmarshalling errors.
client/v2/tx/encoder.go (5)
38-58: FunctiondecodeTxlooks good.The function correctly decodes transaction bytes into an apitx.Tx structure, including error handling for unmarshalling and decoding errors.
60-67: FunctionencodeTxlooks good.The function correctly encodes an apitx.Tx into bytes using protobuf marshaling options, including error handling for unexpected transaction types.
69-91: FunctiondecodeJsonTxlooks good.The function correctly decodes transaction bytes into an apitx.Tx structure using JSON format, including error handling for unmarshalling and decoding errors.
94-101: FunctionencodeJsonTxlooks good.The function correctly encodes an apitx.Tx into bytes using JSON marshaling options, including error handling for unexpected transaction types.
103-119: FunctionprotoTxByteslooks good.The function correctly marshals a transaction into bytes using protobuf marshaling options, including error handling for marshaling errors.
client/v2/tx/types.go (6)
28-40: TypeTxParameterslooks good.The type correctly defines the parameters required for constructing a transaction, with appropriate comments explaining each field.
42-54: TypeAccountConfiglooks good.The type correctly defines the account-related fields in a transaction, with appropriate comments explaining each field.
56-62: TypeGasConfiglooks good.The type correctly defines the gas-related settings for a transaction, with appropriate comments explaining each field.
84-89: TypeFeeConfiglooks good.The type correctly defines the fee details for a transaction, with appropriate comments explaining each field.
106-115: TypeExecutionOptionslooks good.The type correctly defines the settings for transaction execution, with appropriate comments explaining each field.
132-142: TypeTxlooks good.The type correctly defines the interface for transaction operations, with appropriate methods for transaction operations.
client/v2/tx/builder.go (5)
27-44: LGTM! Interface methods are well-defined.The
TxBuilderinterface methods cover all necessary transaction functionalities and are well-defined.
52-81: LGTM! Struct implementation is correct.The
BuilderProviderstruct correctly implementsTxBuilderProviderand provides methods for creating and wrapping transaction builders.
116-166: LGTM! Method implementation is correct.The
getTxmethod correctly convertstxBuildermessages to V2 and handles errors appropriately.
240-252: LGTM! Method implementation is correct.The
SetFeePayermethod correctly sets the fee payer for the transaction and handles errors appropriately.
277-316: LGTM! Method implementation is correct.The
SetSignaturesmethod correctly sets the signatures for the transaction builder and handles errors appropriately.client/v2/tx/config.go (2)
36-42: LGTM! Interface methods are well-defined.The
TxConfiginterface methods cover all necessary functionalities and are well-defined.
69-84: LGTM! Struct implementation is correct.The
ConfigOptionsstruct correctly defines the configuration options for transaction processing.client/v2/tx/builder_test.go (12)
23-48: Ensure initialization of test variables inTestNewBuilderProvider.The test function
TestNewBuilderProvideruses variablesac,decoder, andcdcwhich are not initialized within the test or in a setup function. This could lead to a runtime panic if these are nil.func TestNewBuilderProvider(t *testing.T) { + var ac address.Codec + var decoder *txdecode.Decoder + var cdc codec.BinaryCodec type args struct { addressCodec address.Codec decoder *txdecode.Decoder codec codec.BinaryCodec } // Existing code... }
112-196: Confirm test cases cover both empty and full transaction scenarios inTest_txBuilder_GetTx.The test function
Test_txBuilder_GetTxincludes test cases for both empty and full transactions, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
198-220: Test function for message conversion lacks assertions.The test
Test_msgsV1toAnyV2converts transaction messages but does not assert the expected properties of the resultinganypb.Anyobjects. This makes the test less effective as it does not verify the correctness of the conversion.func Test_msgsV1toAnyV2(t *testing.T) { for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { got, err := msgsV1toAnyV2(tt.msgs) require.NoError(t, err) require.NotNil(t, got) + // Example assertion + require.Equal(t, "/cosmos.tx.v1beta1.MsgIncreaseCounter", got[0].TypeUrl) }) } }
222-248: Confirm test cases cover the conversion ofcodectypes.Anytoanypb.AnyinTest_intoAnyV2.The test function
Test_intoAnyV2includes assertions that verify the correctness of the conversion, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
250-309: Confirm test cases cover different fee scenarios inTest_txBuilder_getFee.The test function
Test_txBuilder_getFeeincludes test cases for different fee scenarios, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
311-365: Confirm test cases cover both empty and full transaction scenarios inTest_txBuilder_GetSigningTxData.The test function
Test_txBuilder_GetSigningTxDataincludes test cases for both empty and full transactions, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
367-399: Confirm test cases cover the message setting inTest_txBuilder_SetMsgs.The test function
Test_txBuilder_SetMsgsincludes assertions that verify the messages are set correctly, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
401-418: Confirm test cases cover the memo setting inTest_txBuilder_SetMemo.The test function
Test_txBuilder_SetMemoincludes assertions that verify the memo is set correctly, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
420-446: Confirm test cases cover the fee amount setting inTest_txBuilder_SetFeeAmount.The test function
Test_txBuilder_SetFeeAmountincludes assertions that verify the fee amount is set correctly, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
448-464: Confirm test cases cover the gas limit setting inTest_txBuilder_SetGasLimit.The test function
Test_txBuilder_SetGasLimitincludes assertions that verify the gas limit is set correctly, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
467-487: Confirm test cases cover the unordered flag setting inTest_txBuilder_SetUnordered.The test function
Test_txBuilder_SetUnorderedincludes assertions that verify the unordered flag is set correctly, which is essential for comprehensive coverage. Ensure these test cases are maintained and updated as necessary.
490-572: Ensure correct handling of multiple and single signatures inTest_txBuilder_SetSignatures.The test cases for setting signatures should include assertions to verify that the signatures are correctly set on the transaction. Currently, the test only checks for errors but does not validate the state of the transaction after setting signatures.
func Test_txBuilder_SetSignatures(t *testing.T) { for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { b := newTxBuilder(ac, decoder, cdc) sigs := tt.signatures() err := b.SetSignatures(sigs...) require.NoError(t, err) + // Verify the state of the transaction + tx, _ := b.GetTx() + require.Equal(t, len(sigs), len(tx.Signatures)) }) } }client/v2/tx/factory.go (5)
45-58: LGTM! Factory initialization looks correct.The
NewFactoryfunction correctly initializes a newFactoryinstance with the provided parameters.
487-506: LGTM! Signature data handling looks correct.The
getSimSignatureDatafunction correctly handles the signature data based on the public key type.
271-395: Consider using propagated context.The function uses
context.Background()which might not respect cancellation or timeouts from an upstream context. Consider modifying the function signature to include acontext.Contextparameter and use it instead.- func (f *Factory) Sign(ctx context.Context, txBuilder TxBuilder, overwriteSig bool) error { + func (f *Factory) Sign(ctx context.Context, txBuilder TxBuilder, overwriteSig bool, ctx context.Context) error {Likely invalid or redundant comment.
199-232: Consider using propagated context.The function uses
context.Background()which might not respect cancellation or timeouts from an upstream context. Consider modifying the function signature to include acontext.Contextparameter and use it instead.- func (f *Factory) UnsignedTxString(msgs ...transaction.Msg) (string, error) { + func (f *Factory) UnsignedTxString(ctx context.Context, msgs ...transaction.Msg) (string, error) { - encoder := f.txConfig.TxJSONEncoder() + encoder := f.txConfig.TxJSONEncoder(ctx)Likely invalid or redundant comment.
397-406: Consider using propagated context.The function uses
context.Background()which might not respect cancellation or timeouts from an upstream context. Consider modifying the function signature to include acontext.Contextparameter and use it instead.- func (f *Factory) getSignBytesAdapter(ctx context.Context, signerData signing.SignerData, builder TxBuilder) ([]byte, error) { + func (f *Factory) getSignBytesAdapter(ctx context.Context, signerData signing.SignerData, builder TxBuilder, ctx context.Context) ([]byte, error) {Likely invalid or redundant comment.
client/v2/tx/README.md (8)
1-12: LGTM! Overview section looks correct.The
Overviewsection correctly lists the key components in thetxpackage.
13-27: LGTM! Architecture section looks correct.The
Architecturesection correctly provides a mermaid diagram and descriptions of the architecture.
29-99: LGTM! Key Components section looks correct.The
Key Componentssection correctly provides detailed descriptions and mermaid diagrams for the key components in thetxpackage.
101-176: LGTM! TxBuilder section looks correct.The
TxBuildersection correctly provides a mermaid diagram and descriptions for theTxBuilder.
178-236: LGTM! Factory section looks correct.The
Factorysection correctly provides a mermaid diagram and descriptions for theFactory.
238-285: LGTM! Encoder/Decoder section looks correct.The
Encoder/Decodersection correctly provides a mermaid diagram and descriptions for the encoder and decoder functionalities.
287-506: LGTM! Sequence Diagrams section looks correct.The
Sequence Diagramssection correctly provides mermaid sequence diagrams for various processes.
508-528: **Fix the grammaticalTools
LanguageTool
[grammar] ~512-~512: The verb ‘Prepare’ does not usually follow articles like ‘a’. Check that ‘Prepare’ is spelled correctly; using ‘Prepare’ as a noun may be non-standard.
Context: ...ackage, typically you would: 1. Create aFactory2. Prepare the account 3. Build an unsigned transa...(A_INFINITIVE)
There was a problem hiding this comment.
Actionable comments posted: 12
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (4)
- client/v2/tx/README.md (1 hunks)
- client/v2/tx/factory.go (1 hunks)
- client/v2/tx/factory_test.go (1 hunks)
- client/v2/tx/tx.go (1 hunks)
Files not reviewed due to server errors (1)
- client/v2/tx/factory.go
Additional context used
Path-based instructions (4)
client/v2/tx/factory_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"client/v2/tx/tx.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/factory.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/README.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
LanguageTool
client/v2/tx/README.md
[grammar] ~513-~513: The verb ‘Prepare’ does not usually follow articles like ‘a’. Check that ‘Prepare’ is spelled correctly; using ‘Prepare’ as a noun may be non-standard.
Context: ...ackage, typically you would: 1. Create aFactory2. Prepare the account 3. Build an unsigned transa...(A_INFINITIVE)
Markdownlint
client/v2/tx/README.md
35-35: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
36-36: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
37-37: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
182-182: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
183-183: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
184-184: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
185-185: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
290-290: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
337-337: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
337-337: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
386-386: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
439-439: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
291-291: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
336-336: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
338-338: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
387-387: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
440-440: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
1-1: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
529-529: null
Files should end with a single newline character(MD047, single-trailing-newline)
Additional comments not posted (1)
client/v2/tx/README.md (1)
1-529: Comprehensive Review ofclient/v2/tx/README.mdThis documentation provides a detailed and structured overview of the
txpackage functionalities, including transaction building, signing, and management. The use of class diagrams and sequence diagrams enhances the clarity of the architectural and operational details.Suggestions and Corrections:
Grammar and Style Consistency:
- Consider using consistent list markers. The document mixes dashes and asterisks. For consistency, choose one style. (MD004)
- Ensure that headings are surrounded by blank lines to improve readability and adhere to Markdown standards. (MD022)
- Fenced code blocks should also be surrounded by blank lines. (MD031)
- The document should start with a top-level heading and end with a newline. (MD041, MD047)
Technical Accuracy and Completeness:
- The sections cover key components and their interactions comprehensively. However, ensure all newly introduced terms or concepts are defined or linked to further resources for new users.
LanguageTool Feedback:
- The phrase "Prepare the account" might be misleading as 'Prepare' is typically not used as a noun. Consider rephrasing to "Prepare for account setup" or similar to clarify the action. (A_INFINITIVE)
Overall, the document is well-organized and informative, providing essential insights into the transaction management system of the Cosmos SDK. Minor adjustments to markdown syntax and some clarifications in language use will enhance its quality.
Tools
LanguageTool
[grammar] ~513-~513: The verb ‘Prepare’ does not usually follow articles like ‘a’. Check that ‘Prepare’ is spelled correctly; using ‘Prepare’ as a noun may be non-standard.
Context: ...ackage, typically you would: 1. Create aFactory2. Prepare the account 3. Build an unsigned transa...(A_INFINITIVE)
Markdownlint
35-35: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
36-36: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
37-37: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
182-182: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
183-183: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
184-184: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
185-185: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
290-290: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
337-337: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
337-337: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
386-386: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
439-439: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
291-291: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
336-336: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
338-338: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
387-387: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
440-440: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
1-1: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
529-529: null
Files should end with a single newline character(MD047, single-trailing-newline)
|
@coderabbitai stop |
|
Tip For best results, initiate chat on the files or code changes. @JulianToledano, I've stopped as requested. If there's anything else you need, just let me know! |
| @@ -0,0 +1,307 @@ | |||
| package tx | |||
There was a problem hiding this comment.
Can we just drop the aux builder for v2? cc @tac0turtle. Can textual replace it?
| return nil, 0, err | ||
| } | ||
|
|
||
| return simRes, uint64(f.gasAdjustment() * float64(simRes.GasInfo.GasUsed)), nil |
Check notice
Code scanning / CodeQL
Floating point arithmetic Note
|
|
||
| import ( | ||
| "fmt" | ||
| "reflect" |
Check notice
Code scanning / CodeQL
Sensitive package import Note
remove PreprocessTxFn and ExtensionOptions, fix godoc typos
|
Forgot about, this I'll try to review tomorrow. |
There was a problem hiding this comment.
I still see some comments of mine left unanswered or unimplemented. Could you have a look @JulianToledano ?
| @@ -0,0 +1,307 @@ | |||
| package tx | |||
| @@ -147,11 +147,11 @@ func (a *consensusAddressValue) Set(s string) error { | |||
| return nil | |||
| } | |||
|
|
|||
| func getKeyringFromCtx(ctx *context.Context) keyring.Keyring { | |||
| func getKeyringFromCtx(ctx *context.Context, ac address.Codec) keyring.Keyring { | |||
There was a problem hiding this comment.
Not sure but isn't address.Codec available inside Context ?
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range and nitpick comments (2)
client/v2/tx/types.go (1)
128-196: Consider refactoring thetxParamsFromFlagSetfunction.The
txParamsFromFlagSetfunction is quite large and complex, handling the extraction and parsing of various transaction parameters from flags. While the function is well-documented and handles errors properly, it could benefit from refactoring.Consider breaking down the function into smaller, more focused functions that handle specific parameter extractions. This will improve readability, maintainability, and testability of the code.
client/v2/tx/builder.go (1)
71-78: Evaluate the necessity of theWrapTxBuildermethod.The
WrapTxBuildermethod wraps an existing transaction into atxBuilderobject. However, the TODO comment raises a valid concern about the necessity of this method.Consider the following:
- If this functionality is rarely used or can be integrated into the
NewTxBuildermethod, it may introduce unnecessary complexity to the interface.- If it remains necessary, ensure that its usage is justified and well-documented to avoid confusion about when to use
NewTxBuilderversusWrapTxBuilder.
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (7)
- client/v2/autocli/keyring/keyring.go (1 hunks)
- client/v2/tx/builder.go (1 hunks)
- client/v2/tx/encoder.go (1 hunks)
- client/v2/tx/factory.go (1 hunks)
- client/v2/tx/factory_test.go (1 hunks)
- client/v2/tx/tx.go (1 hunks)
- client/v2/tx/types.go (1 hunks)
Additional context used
Path-based instructions (7)
client/v2/autocli/keyring/keyring.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/encoder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/types.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/tx.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/builder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/factory_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"client/v2/tx/factory.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Additional comments not posted (60)
client/v2/autocli/keyring/keyring.go (2)
52-55: LGTM!The
KeyTypefunction correctly delegates the call to the underlyingKeyringimplementation to retrieve the key type based on the provided name. The function signature and implementation adhere to the Uber Golang style guide.
57-60: LGTM!The
KeyInfofunction correctly delegates the call to the underlyingKeyringimplementation to retrieve comprehensive information about a key based on the provided name or address. The function signature and implementation adhere to the Uber Golang style guide.client/v2/tx/encoder.go (6)
39-58: LGTM!The
decodeTxfunction correctly decodes transaction bytes into anapitx.Txstructure using the provided binary codec and decoder. It handles errors appropriately and follows the expected logic.
61-67: LGTM!The
encodeTxfunction correctly encodes anapitx.Txinto bytes using the protobuf marshaling options. It performs type assertion to ensure the providedTxis of the expected*wrappedTxtype and handles the error case appropriately.
70-92: LGTM!The
decodeJsonTxfunction correctly decodes JSON transaction bytes into anapitx.Txstructure using the provided binary codec and decoder. It handles errors appropriately and follows the expected logic.
95-101: LGTM!The
encodeJsonTxfunction correctly encodes anapitx.Txinto bytes using the JSON marshaling options. It performs type assertion to ensure the providedTxis of the expected*wrappedTxtype and handles the error case appropriately.
103-119: LGTM!The
protoTxBytesfunction correctly marshals the components of atxv1beta1.Txstructure into a raw transaction format. It handles errors appropriately and follows the expected logic.
1-119: Code conforms to the Uber Golang style guide.The file follows the recommended conventions and best practices outlined in the Uber Golang style guide, including:
- Appropriate package naming
- Grouping and separation of import statements
- Consistent use of camelCase for variable and function names
- Proper function signatures and variable declarations
- Recommended error handling style
- Avoidance of global variables and init functions
No deviations from the style guide were found.
client/v2/tx/types.go (9)
20-25: LGTM!The
HasValidateBasicinterface is a clean copy from the SDK to avoid an import cycle. The naming follows Go conventions and the comment justifies the duplication.
27-38: Excellent struct design!The
TxParametersstruct is well-designed with clear field names and comments. The use of struct composition to group related fields into sub-configs enhances readability and maintainability. Great job!
40-52: LGTM!The
AccountConfigstruct is well-defined with clear field names and comments. The fields cover all the necessary account-related information for a transaction.
54-60: LGTM!The
GasConfigstruct is well-defined with clear field names and comments. It captures all the necessary gas-related settings for a transaction.
78-83: LGTM!The
FeeConfigstruct is well-defined with clear field names and comments. It captures all the necessary fee-related details for a transaction.
85-98: LGTM!The
NewFeeConfigfunction is well-implemented. It properly parses and normalizes the fees and returns an error if parsing fails. The function is well-documented and follows Go conventions.
100-105: LGTM!The
ExecutionOptionsstruct is well-defined with clear field names and comments. It captures the necessary settings for transaction execution.
107-114: LGTM!The
GasEstimateResponsestruct is well-defined with a clear field name and comment. TheStringmethod provides a readable string representation of the response.
116-126: LGTM!The
Txinterface is well-defined and extends thetransaction.Txinterface with additional transaction-related methods. It provides a clear contract for transaction operations.client/v2/tx/tx.go (10)
26-53: LGTM!The
GenerateOrBroadcastTxCLIfunction is well-structured and handles the transaction lifecycle effectively based on the provided user flags. It validates messages, creates a transaction factory, and determines the appropriate action to take. The error handling is also properly implemented.
58-82: LGTM!The
newFactoryfunction properly initializes a new transaction factory by setting up the necessary components such as the keyring, transaction config, and account retriever. The error handling is also properly implemented.
88-101: LGTM!The
validateMessagesfunction properly validates all messages before generating or broadcasting the transaction. It checks if each message implements theHasValidateBasicinterface and calls theValidateBasicmethod if available. The error handling is also properly implemented.
104-111: LGTM!The
generateAuxSignerDatafunction properly generates and prints the auxiliary signer data. It calls themakeAuxSignerDatafunction to generate the data and handles any errors returned by it. The function also uses the provided context to print the generated data.
116-123: LGTM!The
generateOnlyfunction properly prepares the transaction and prints the unsigned transaction string. It calls theUnsignedTxStringmethod of the transaction factory to generate the string and handles any errors returned by it. The function also uses the provided context to print the generated string.
127-135: LGTM!The
dryRunfunction properly performs a dry run of the transaction to estimate the gas required. It calls theSimulatemethod of the transaction factory to simulate the transaction and handles any errors returned by it. The function also prints the estimated gas to the standard error using thefmt.Fprintffunction.
138-146: LGTM!The
SimulateTxfunction properly simulates a transaction and returns the simulation response. It creates a new transaction factory using thenewFactoryfunction and handles any errors returned by it. The function then calls theSimulatemethod of the factory to simulate the transaction and returns the simulation response along with any error.
151-212: LGTM!The
BroadcastTxfunction properly generates, signs, and broadcasts a transaction with the given set of messages. It handles gas simulation, builds an unsigned transaction, prompts for user confirmation, signs the transaction, and broadcasts it to a CometBFT node. The function also handles errors and returns them to the caller.
215-264: LGTM!The
makeAuxSignerDatafunction properly generates anAuxSignerDatafrom the client inputs. It sets various fields of theAuxSignerDatasuch as address, account number, sequence, messages, sign mode, public key, chain ID, and signature using the appropriate methods of theAuxTxBuilder. The function also handles errors and returns them to the caller.
267-300: LGTM!The
countDirectSignersfunction properly counts the number of DIRECT signers in a signature data. It uses a switch statement to handle different types of signature data and recursively counts the number of DIRECT signers. The function also panics with an "unreachable case" message for any unsupported signature data type.The
getSignModefunction properly returns the correspondingapitxsigning.SignModebased on the provided mode string. It uses a switch statement to map the mode string to the correspondingapitxsigning.SignModeand returnsapitxsigning.SignMode_SIGN_MODE_UNSPECIFIEDif no match is found.client/v2/tx/builder.go (11)
57-63: LGTM!The
NewBuilderProviderconstructor function is implemented correctly, initializing a newBuilderProviderinstance with the provided parameters.
66-68: LGTM!The
NewTxBuildermethod is implemented correctly, creating a newTxBuilderinstance by calling thenewTxBuilderfunction with the appropriate parameters from theBuilderProviderinstance.
101-107: LGTM!The
newTxBuilderfunction is implemented correctly, initializing a newtxBuilderinstance with the provided parameters.
110-112: LGTM!The
GetTxmethod is implemented correctly, convertingtxBuildermessages to V2 by calling thegetTxmethod and returning the result.
114-165: LGTM!The
getTxmethod is implemented correctly, convertingtxBuildermessages to V2 and creating awrappedTx. It follows the necessary steps, such as converting messages, creating aTxBodyandAuthInfo, marshaling the data, and decoding theTxRawbytes. The error handling is appropriate, returning any errors encountered during the process.
170-195: LGTM!The
getFeemethod is implemented correctly, computing the transaction fee information based on thetxBuilderfields. It properly handles the conversion of granter and payer addresses from bytes to string using theaddressCodec. The logic follows the necessary steps to create a validapitx.Feestruct.
198-211: LGTM!The
GetSigningTxDatamethod is implemented correctly, returning aTxDatawith thetxBuilderinfo. It calls thegetTxmethod to get thewrappedTxand creates asigning.TxDatastruct with the relevant fields from thewrappedTx. The logic follows the necessary steps to create a validsigning.TxDatastruct.
219-222: LGTM!The
SetMemomethod is implemented correctly, setting thememofield oftxBuilderwith the provided memo string.
224-227: LGTM!The
SetFeeAmountmethod is implemented correctly, setting thefeesfield oftxBuilderwith the provided coins.
229-232: LGTM!The
SetGasLimitmethod is implemented correctly, setting thegasLimitfield oftxBuilderwith the provided gas limit.
234-237: LGTM!The
SetTimeoutTimestampmethod is implemented correctly, setting thetimeoutTimestampfield oftxBuilderwith the provided timeout timestamp.client/v2/tx/factory_test.go (9)
24-53: LGTM!The
TestFactory_prepareTxParamsfunction is well-structured and covers the important scenarios. The assertions correctly check the error conditions.
55-123: LGTM!The
TestFactory_BuildUnsignedTxfunction is well-structured and covers the important scenarios, including providing fees and gas prices. The assertions correctly check the error conditions and the returned unsigned transaction.
125-165: LGTM!The
TestFactory_calculateGasfunction is well-structured and covers the successful scenario. The assertions correctly check the error condition and the updated gas configuration.
167-208: LGTM!The
TestFactory_Simulatefunction is well-structured and covers the successful scenario. The assertions correctly check the error condition and the simulation results.
210-242: LGTM!The
TestFactory_BuildSimTxfunction is well-structured and covers the successful scenario. The assertions correctly check the error condition and the returned simulated transaction.
244-293: LGTM!The
TestFactory_Signfunction is well-structured and covers the successful scenario. The assertions correctly check the error condition, the signatures, and the signer infos.
295-364: LGTM!The
TestFactory_getSignBytesAdapterfunction is well-structured and covers the important scenarios, including when the sign mode is not specified. The assertions correctly check the error conditions and the returned sign bytes adapter.
366-393: LGTM!The
Test_validateMemofunction is well-structured and covers the important scenarios, including empty memo, valid memo, and invalid memo. The assertions correctly check the error conditions.
395-455: LGTM!The
TestFactory_WithFunctionsfunction is well-structured and covers the importantWith*methods, includingWithGas,WithSequence, andWithAccountNumber. The assertions correctly check the updated factory parameters.client/v2/tx/factory.go (13)
37-47: LGTM!The
Factorystruct encapsulates the necessary dependencies and configurations for building and signing transactions. The fields are appropriately named and typed.
49-68: LGTM!The
NewFactoryFromFlagSetfunction follows a clear flow to initialize aFactoryinstance based on command-line flags. It validates the flag set, retrieves transaction parameters, prepares them, and returns a newFactoryinstance. The error handling is appropriate.
70-83: LGTM!The
NewFactoryfunction is a simple constructor that initializes aFactoryinstance with the provided parameters and returns it along with a nil error.
85-114: LGTM!The
validateFlagSetfunction performs necessary validations on the provided flag set based on the operation mode. It checks for required flags, conflicts between flags, and the presence of the chain ID. The error messages are clear and informative.
116-144: LGTM!The
prepareTxParamsfunction ensures the account exists and sets the account number and sequence if they are zero. It follows a clear flow, handles errors appropriately, and returns the updated transaction parameters.
146-205: LGTM!The
BuildUnsignedTxfunction builds an unsigned transaction given a set of messages. It calculates fees based on gas prices and gas limit, validates the memo field, creates a new transaction builder, sets the necessary fields, and returns the builder. The function follows a clear flow and handles errors appropriately.
207-214: LGTM!The
BuildsSignedTxfunction is a simple wrapper that builds an unsigned transaction usingBuildUnsignedTxand signs it using thesignmethod. It handles errors appropriately.
216-226: LGTM!The
calculateGasfunction is a simple wrapper that simulates the transaction execution to obtain the adjusted gas amount and updates the factory's gas value. It handles errors appropriately.
228-245: LGTM!The
Simulatefunction simulates the execution of a transaction and returns the simulation response and the adjusted gas amount. It follows a clear flow, building a simulation transaction, sending a simulation request, retrieving the response, calculating the adjusted gas amount, and returning the results. The error handling is appropriate.
247-280: LGTM!The
UnsignedTxStringfunction generates an unsigned transaction and returns it as a JSON string. It follows a clear flow, calculating gas if requested, building an unsigned transaction, retrieving the JSON encoder, encoding the transaction, and returning the JSON string. The error handling is appropriate.
282-317: LGTM!The
BuildSimTxfunction creates an unsigned transaction with an empty single signature for simulation purposes. It follows a clear flow, building an unsigned transaction, retrieving the simulation public key, creating an empty signature, setting the signature on the builder, retrieving the encoder, encoding the transaction, and returning the encoded transaction. The error handling is appropriate.
319-441: LGTM!The
signfunction signs a given transaction with a named key. It follows a complex flow with multiple steps, including checking the keybase, retrieving the sign mode, public key, and address, creating the signer data and signature, setting the signature on the builder, retrieving the signed transaction, checking for multiple signers, retrieving the sign bytes, signing the bytes, creating a new signature, setting the new signature on the builder, and returning the signed transaction. The error handling is appropriate, covering various failure scenarios.
443-452: LGTM!The
getSignBytesAdapterfunction is a simple adapter that retrieves the signing transaction data from the transaction builder and generates the sign bytes using the sign mode handler. It handles errors appropriately.
|
@coderabbitai stop |
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (4)
client/v2/tx/README.md (4)
35-37: Use consistent unordered list markersIn lines 35-37, the list items use dashes
-instead of asterisks*. For consistency and adherence to Markdown style guidelines, consider changing the list markers to asterisks.Apply this diff to correct the list markers:
- - Encoding and decoding - - Sign mode handling - - Signature JSON marshaling/unmarshaling + * Encoding and decoding + * Sign mode handling + * Signature JSON marshaling/unmarshalingTools
Markdownlint
35-35: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
36-36: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
37-37: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
180-183: Use consistent unordered list markersIn lines 180-183, the list items use dashes
-instead of asterisks*. For consistency and adherence to Markdown style guidelines, consider changing the list markers to asterisks.Apply this diff to correct the list markers:
- - Account preparation - - Gas calculation - - Transaction simulation - - Unsigned transaction building + * Account preparation + * Gas calculation + * Transaction simulation + * Unsigned transaction buildingTools
Markdownlint
180-180: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
181-181: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
182-182: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
183-183: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
288-288: Add blank lines around headingsHeadings on lines 288, 335, 384, and 437 are not surrounded by blank lines. To improve readability and adhere to Markdown conventions, add a blank line before and after each heading.
Apply these diffs:
At line 288:
-#### Generate Aux Signer Data + +#### Generate Aux Signer Data +At line 335:
-#### Generate Only + +#### Generate Only +At line 384:
-#### DryRun + +#### DryRun +At line 437:
-#### Generate and Broadcast Tx + +#### Generate and Broadcast Tx +Also applies to: 335-335, 384-384, 437-437
Tools
Markdownlint
288-288: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
527-527: Ensure the file ends with a single newline characterThe file should end with a single trailing newline character to adhere to POSIX standards and improve compatibility with various tools.
Tools
Markdownlint
527-527: null
Files should end with a single newline character(MD047, single-trailing-newline)
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (6)
- client/v2/internal/account/retriever.go (1 hunks)
- client/v2/tx/README.md (1 hunks)
- client/v2/tx/builder.go (1 hunks)
- client/v2/tx/flags.go (1 hunks)
- client/v2/tx/tx.go (1 hunks)
- client/v2/tx/types.go (1 hunks)
Files skipped from review as they are similar to previous changes (2)
- client/v2/tx/tx.go
- client/v2/tx/types.go
Additional context used
Path-based instructions (4)
client/v2/internal/account/retriever.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/README.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"client/v2/tx/builder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.client/v2/tx/flags.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
LanguageTool
client/v2/tx/README.md
[grammar] ~511-~511: The verb ‘Prepare’ does not usually follow articles like ‘a’. Check that ‘Prepare’ is spelled correctly; using ‘Prepare’ as a noun may be non-standard.
Context: ...ackage, typically you would: 1. Create aFactory2. Prepare the account 3. Build an unsigned transa...(A_INFINITIVE)
Markdownlint
client/v2/tx/README.md
35-35: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
36-36: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
37-37: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
180-180: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
181-181: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
182-182: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
183-183: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
288-288: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
335-335: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
335-335: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
384-384: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
437-437: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines(MD022, blanks-around-headings)
289-289: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
334-334: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
336-336: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
385-385: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
438-438: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
1-1: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
527-527: null
Files should end with a single newline character(MD047, single-trailing-newline)
Additional comments not posted (20)
client/v2/tx/flags.go (1)
37-53: LGTM!The
parseGasSettingfunction is well-implemented and adheres to the Uber Golang style guide. It provides a flexible way to manage gas settings in transaction processing by allowing both automatic and manual gas settings. The function correctly handles the three scenarios using a switch statement and returns appropriate values for each scenario. It also returns a clear error message if parsing fails.The function enhances the transaction handling capabilities of the package and is a valuable addition to the codebase.
client/v2/internal/account/retriever.go (6)
1-24: LGTM!The package declaration, imports, and constant declaration are all in order. The constant
GRPCBlockHeightHeaderis clearly named and follows the naming convention.
25-41: LGTM!The interface declarations for
AccountandAccountRetrieverare well-defined and provide a clear abstraction for account-related functionality. The methods have appropriate signatures and return types.
43-56: LGTM!The
accountRetrieverstruct and its constructor functionNewAccountRetrieverare well-implemented. The struct has appropriate fields, and the constructor function takes the necessary dependencies as parameters and returns a pointer to theaccountRetrieverinstance.
58-62: LGTM!The
GetAccountmethod correctly implements theAccountRetrieverinterface by delegating the account retrieval to theGetAccountWithHeightmethod and discarding the block height.
97-103: LGTM!The
EnsureExistsmethod correctly implements theAccountRetrieverinterface by using theGetAccountmethod to check if an account exists and returning an error if it does not.
105-116: LGTM!The
GetAccountNumberSequencemethod correctly implements theAccountRetrieverinterface by using theGetAccountmethod to retrieve the account and handling the case when the account is not found. The method returns the account number and sequence if the account is found, and zero values if it is not.client/v2/tx/builder.go (13)
56-62: LGTM!The
NewBuilderProviderconstructor function is implemented correctly, taking the necessary parameters and returning a newBuilderProviderinstance.
65-67: LGTM!The
NewTxBuildermethod is implemented correctly, utilizing thenewTxBuilderfunction to create a newTxBuilderinstance with the necessary fields from theBuilderProvider.
90-96: LGTM!The
newTxBuilderfunction is implemented correctly, taking the necessary parameters and returning a newtxBuilderinstance.
99-101: LGTM!The
GetTxmethod is implemented correctly, delegating the conversion oftxBuildermessages to V2 and returning the resultingTxby calling thegetTxmethod.
103-154: LGTM!The
getTxmethod is implemented correctly, following these steps:
- Convert messages from V1 to V2.
- Create a new
TxBodywith the converted messages and other fields.- Get the fee information using the
getFeemethod.- Create a new
AuthInfowith the signer infos and fee.- Marshal the
TxBodyandAuthInfo.- Create a new
TxRawwith the marshaled body, auth info, and signatures.- Marshal the
TxRaw.- Decode the marshaled
TxRawusing thedecoder.- Return a new
wrappedTxwith the decodedTxandcodec.The error handling is in place, and the logic is sound.
159-184: LGTM!The
getFeemethod is implemented correctly, following these steps:
- Check if the
granterfield is set and convert it from bytes to string using theaddressCodec.- Check if the
payerfield is set and convert it from bytes to string using theaddressCodec.- Create a new
apitx.Feeinstance with thefees,gasLimit,payer, andgranterfields.- Return the
apitx.Feeinstance and any error that occurred during the conversion.The error handling is in place, and the logic is sound.
187-200: LGTM!The
GetSigningTxDatamethod is implemented correctly, following these steps:
- Call the
getTxmethod to get thewrappedTxinstance.- Create a new
signing.TxDatainstance with the necessary fields from thewrappedTx.- Return the
signing.TxDatainstance and any error that occurred during thegetTxcall.The error handling is in place, and the logic is sound.
202-206: LGTM!The
SetMsgsmethod is implemented correctly, taking a variadic parameter of typetransaction.Msgand assigning it to themsgsfield oftxBuilder. It returnsnilas the error, indicating that the operation was successful.
209-211: LGTM!The
SetMemomethod is implemented correctly, taking a string parametermemoand assigning it to thememofield oftxBuilder.
214-216: LGTM!The
SetFeeAmountmethod is implemented correctly, taking a slice ofbase.Coinas a parameter and assigning it to thefeesfield oftxBuilder.
219-221: LGTM!The
SetGasLimitmethod is implemented correctly, taking auint64parametergasLimitand assigning it to thegasLimitfield oftxBuilder.
224-226: LGTM!The
SetTimeoutTimestampmethod is implemented correctly, taking atime.TimeparametertimeoutHeightand assigning it to thetimeoutTimestampfield oftxBuilder.
228-240: LGTM!The
SetFeePayermethod is implemented correctly, following these steps:
- Check if the
feePayeris an empty string and returnnilif true.- Convert the
feePayerstring to bytes using theaddressCodec.- Assign the converted bytes to the
payerfield oftxBuilder.- Return any error that occurred during the conversion.
The error handling is in place, and the logic is sound.
|
@JulianToledano, I've paused the automatic reviews as requested. Actions performedReviews paused. |
Description
Ref:
#18580
#19738
Closes:
#19433
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...
!in the type prefix if API or client breaking changeCHANGELOG.mdReviewers 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...
Summary by CodeRabbit
New Features
KeyTypeandKeyInfoto the keyring interface for retrieving key type and key information.Improvements
Bug Fixes
signfunction.Tests