-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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(client/v2): factory #20623
feat(client/v2): factory #20623
Conversation
Note Reviews pausedUse the following commands to manage reviews:
📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few comments, looks very good 🚀
remove factory withs, parsing gas and fees,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
Outside diff range and nitpick comments (2)
client/v2/tx/types.go (1)
128-196
: Consider refactoring thetxParamsFromFlagSet
function.The
txParamsFromFlagSet
function 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 theWrapTxBuilder
method.The
WrapTxBuilder
method wraps an existing transaction into atxBuilder
object. 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
NewTxBuilder
method, 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
NewTxBuilder
versusWrapTxBuilder
.
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
KeyType
function correctly delegates the call to the underlyingKeyring
implementation 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
KeyInfo
function correctly delegates the call to the underlyingKeyring
implementation 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
decodeTx
function correctly decodes transaction bytes into anapitx.Tx
structure using the provided binary codec and decoder. It handles errors appropriately and follows the expected logic.
61-67
: LGTM!The
encodeTx
function correctly encodes anapitx.Tx
into bytes using the protobuf marshaling options. It performs type assertion to ensure the providedTx
is of the expected*wrappedTx
type and handles the error case appropriately.
70-92
: LGTM!The
decodeJsonTx
function correctly decodes JSON transaction bytes into anapitx.Tx
structure using the provided binary codec and decoder. It handles errors appropriately and follows the expected logic.
95-101
: LGTM!The
encodeJsonTx
function correctly encodes anapitx.Tx
into bytes using the JSON marshaling options. It performs type assertion to ensure the providedTx
is of the expected*wrappedTx
type and handles the error case appropriately.
103-119
: LGTM!The
protoTxBytes
function correctly marshals the components of atxv1beta1.Tx
structure 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
HasValidateBasic
interface 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
TxParameters
struct 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
AccountConfig
struct 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
GasConfig
struct is well-defined with clear field names and comments. It captures all the necessary gas-related settings for a transaction.
78-83
: LGTM!The
FeeConfig
struct is well-defined with clear field names and comments. It captures all the necessary fee-related details for a transaction.
85-98
: LGTM!The
NewFeeConfig
function 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
ExecutionOptions
struct is well-defined with clear field names and comments. It captures the necessary settings for transaction execution.
107-114
: LGTM!The
GasEstimateResponse
struct is well-defined with a clear field name and comment. TheString
method provides a readable string representation of the response.
116-126
: LGTM!The
Tx
interface is well-defined and extends thetransaction.Tx
interface with additional transaction-related methods. It provides a clear contract for transaction operations.client/v2/tx/tx.go (10)
26-53
: LGTM!The
GenerateOrBroadcastTxCLI
function 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
newFactory
function 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
validateMessages
function properly validates all messages before generating or broadcasting the transaction. It checks if each message implements theHasValidateBasic
interface and calls theValidateBasic
method if available. The error handling is also properly implemented.
104-111
: LGTM!The
generateAuxSignerData
function properly generates and prints the auxiliary signer data. It calls themakeAuxSignerData
function 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
generateOnly
function properly prepares the transaction and prints the unsigned transaction string. It calls theUnsignedTxString
method 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
dryRun
function properly performs a dry run of the transaction to estimate the gas required. It calls theSimulate
method 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.Fprintf
function.
138-146
: LGTM!The
SimulateTx
function properly simulates a transaction and returns the simulation response. It creates a new transaction factory using thenewFactory
function and handles any errors returned by it. The function then calls theSimulate
method of the factory to simulate the transaction and returns the simulation response along with any error.
151-212
: LGTM!The
BroadcastTx
function 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
makeAuxSignerData
function properly generates anAuxSignerData
from the client inputs. It sets various fields of theAuxSignerData
such 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
countDirectSigners
function 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
getSignMode
function properly returns the correspondingapitxsigning.SignMode
based on the provided mode string. It uses a switch statement to map the mode string to the correspondingapitxsigning.SignMode
and returnsapitxsigning.SignMode_SIGN_MODE_UNSPECIFIED
if no match is found.client/v2/tx/builder.go (11)
57-63
: LGTM!The
NewBuilderProvider
constructor function is implemented correctly, initializing a newBuilderProvider
instance with the provided parameters.
66-68
: LGTM!The
NewTxBuilder
method is implemented correctly, creating a newTxBuilder
instance by calling thenewTxBuilder
function with the appropriate parameters from theBuilderProvider
instance.
101-107
: LGTM!The
newTxBuilder
function is implemented correctly, initializing a newtxBuilder
instance with the provided parameters.
110-112
: LGTM!The
GetTx
method is implemented correctly, convertingtxBuilder
messages to V2 by calling thegetTx
method and returning the result.
114-165
: LGTM!The
getTx
method is implemented correctly, convertingtxBuilder
messages to V2 and creating awrappedTx
. It follows the necessary steps, such as converting messages, creating aTxBody
andAuthInfo
, marshaling the data, and decoding theTxRaw
bytes. The error handling is appropriate, returning any errors encountered during the process.
170-195
: LGTM!The
getFee
method is implemented correctly, computing the transaction fee information based on thetxBuilder
fields. 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.Fee
struct.
198-211
: LGTM!The
GetSigningTxData
method is implemented correctly, returning aTxData
with thetxBuilder
info. It calls thegetTx
method to get thewrappedTx
and creates asigning.TxData
struct with the relevant fields from thewrappedTx
. The logic follows the necessary steps to create a validsigning.TxData
struct.
219-222
: LGTM!The
SetMemo
method is implemented correctly, setting thememo
field oftxBuilder
with the provided memo string.
224-227
: LGTM!The
SetFeeAmount
method is implemented correctly, setting thefees
field oftxBuilder
with the provided coins.
229-232
: LGTM!The
SetGasLimit
method is implemented correctly, setting thegasLimit
field oftxBuilder
with the provided gas limit.
234-237
: LGTM!The
SetTimeoutTimestamp
method is implemented correctly, setting thetimeoutTimestamp
field oftxBuilder
with the provided timeout timestamp.client/v2/tx/factory_test.go (9)
24-53
: LGTM!The
TestFactory_prepareTxParams
function is well-structured and covers the important scenarios. The assertions correctly check the error conditions.
55-123
: LGTM!The
TestFactory_BuildUnsignedTx
function 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_calculateGas
function 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_Simulate
function is well-structured and covers the successful scenario. The assertions correctly check the error condition and the simulation results.
210-242
: LGTM!The
TestFactory_BuildSimTx
function 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_Sign
function 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_getSignBytesAdapter
function 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_validateMemo
function 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_WithFunctions
function 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
Factory
struct encapsulates the necessary dependencies and configurations for building and signing transactions. The fields are appropriately named and typed.
49-68
: LGTM!The
NewFactoryFromFlagSet
function follows a clear flow to initialize aFactory
instance based on command-line flags. It validates the flag set, retrieves transaction parameters, prepares them, and returns a newFactory
instance. The error handling is appropriate.
70-83
: LGTM!The
NewFactory
function is a simple constructor that initializes aFactory
instance with the provided parameters and returns it along with a nil error.
85-114
: LGTM!The
validateFlagSet
function 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
prepareTxParams
function 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
BuildUnsignedTx
function 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
BuildsSignedTx
function is a simple wrapper that builds an unsigned transaction usingBuildUnsignedTx
and signs it using thesign
method. It handles errors appropriately.
216-226
: LGTM!The
calculateGas
function 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
Simulate
function 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
UnsignedTxString
function 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
BuildSimTx
function 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
sign
function 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
getSignBytesAdapter
function 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Outside diff range and nitpick comments (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 aFactory
2. 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
parseGasSetting
function 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
GRPCBlockHeightHeader
is clearly named and follows the naming convention.
25-41
: LGTM!The interface declarations for
Account
andAccountRetriever
are well-defined and provide a clear abstraction for account-related functionality. The methods have appropriate signatures and return types.
43-56
: LGTM!The
accountRetriever
struct and its constructor functionNewAccountRetriever
are well-implemented. The struct has appropriate fields, and the constructor function takes the necessary dependencies as parameters and returns a pointer to theaccountRetriever
instance.
58-62
: LGTM!The
GetAccount
method correctly implements theAccountRetriever
interface by delegating the account retrieval to theGetAccountWithHeight
method and discarding the block height.
97-103
: LGTM!The
EnsureExists
method correctly implements theAccountRetriever
interface by using theGetAccount
method to check if an account exists and returning an error if it does not.
105-116
: LGTM!The
GetAccountNumberSequence
method correctly implements theAccountRetriever
interface by using theGetAccount
method 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
NewBuilderProvider
constructor function is implemented correctly, taking the necessary parameters and returning a newBuilderProvider
instance.
65-67
: LGTM!The
NewTxBuilder
method is implemented correctly, utilizing thenewTxBuilder
function to create a newTxBuilder
instance with the necessary fields from theBuilderProvider
.
90-96
: LGTM!The
newTxBuilder
function is implemented correctly, taking the necessary parameters and returning a newtxBuilder
instance.
99-101
: LGTM!The
GetTx
method is implemented correctly, delegating the conversion oftxBuilder
messages to V2 and returning the resultingTx
by calling thegetTx
method.
103-154
: LGTM!The
getTx
method is implemented correctly, following these steps:
- Convert messages from V1 to V2.
- Create a new
TxBody
with the converted messages and other fields.- Get the fee information using the
getFee
method.- Create a new
AuthInfo
with the signer infos and fee.- Marshal the
TxBody
andAuthInfo
.- Create a new
TxRaw
with the marshaled body, auth info, and signatures.- Marshal the
TxRaw
.- Decode the marshaled
TxRaw
using thedecoder
.- Return a new
wrappedTx
with the decodedTx
andcodec
.The error handling is in place, and the logic is sound.
159-184
: LGTM!The
getFee
method is implemented correctly, following these steps:
- Check if the
granter
field is set and convert it from bytes to string using theaddressCodec
.- Check if the
payer
field is set and convert it from bytes to string using theaddressCodec
.- Create a new
apitx.Fee
instance with thefees
,gasLimit
,payer
, andgranter
fields.- Return the
apitx.Fee
instance and any error that occurred during the conversion.The error handling is in place, and the logic is sound.
187-200
: LGTM!The
GetSigningTxData
method is implemented correctly, following these steps:
- Call the
getTx
method to get thewrappedTx
instance.- Create a new
signing.TxData
instance with the necessary fields from thewrappedTx
.- Return the
signing.TxData
instance and any error that occurred during thegetTx
call.The error handling is in place, and the logic is sound.
202-206
: LGTM!The
SetMsgs
method is implemented correctly, taking a variadic parameter of typetransaction.Msg
and assigning it to themsgs
field oftxBuilder
. It returnsnil
as the error, indicating that the operation was successful.
209-211
: LGTM!The
SetMemo
method is implemented correctly, taking a string parametermemo
and assigning it to thememo
field oftxBuilder
.
214-216
: LGTM!The
SetFeeAmount
method is implemented correctly, taking a slice ofbase.Coin
as a parameter and assigning it to thefees
field oftxBuilder
.
219-221
: LGTM!The
SetGasLimit
method is implemented correctly, taking auint64
parametergasLimit
and assigning it to thegasLimit
field oftxBuilder
.
224-226
: LGTM!The
SetTimeoutTimestamp
method is implemented correctly, taking atime.Time
parametertimeoutHeight
and assigning it to thetimeoutTimestamp
field oftxBuilder
.
228-240
: LGTM!The
SetFeePayer
method is implemented correctly, following these steps:
- Check if the
feePayer
is an empty string and returnnil
if true.- Convert the
feePayer
string to bytes using theaddressCodec
.- Assign the converted bytes to the
payer
field 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK! we can simplify more in follow-ups if needed
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.md
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...
Summary by CodeRabbit
New Features
KeyType
andKeyInfo
to the keyring interface for retrieving key type and key information.Improvements
Bug Fixes
sign
function.Tests