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
|
![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: 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. |
JulianToledano
changed the title
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