feat(client/v2): support definitions of inner messages #22890
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces enhancements to the AutoCLI functionality in the Cosmos SDK client/v2 module. The changes focus on improving the handling of positional arguments, particularly for nested message fields. The modifications include updates to the flag builder, message binder, and associated test cases. A new method for flattening inner message fields has been implemented, allowing more flexible command argument parsing and improved user experience when working with complex message structures. Changes
Assessment against linked issues
Suggested labels
Suggested reviewers
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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
|
client/v2/autocli/flag/builder.go
Outdated
| field := fields.ByName(protoreflect.Name(arg.ProtoField)) | ||
| if field == nil { | ||
| return nil, fmt.Errorf("can't find field %s on %s", arg.ProtoField, messageType.Descriptor().FullName()) | ||
| if arg.FlattenFields { |
There was a problem hiding this comment.
We actually don't want the user to have to precise this in their autocli options.
I think ideally it should just work.
if you put permissions you it set the whole struct. If you put permissions.level it it checks the inner field. I think splitting by . may do the job here right.
The big q is how many layer do we accept. Can you do permissions.foo.bar as well?
There was a problem hiding this comment.
ok. If you set only permissions should it flatten the whole struct or should expect a json?
In the first case, should we provide an option to specify a json file? it may be better ux if message is really big.
About the layer that's a good question. I'll try to find a recursive way so there's no limit to it.
There was a problem hiding this comment.
I meant, it should expect a json yeah, like today
There was a problem hiding this comment.
In the first case, should we provide an option to specify a json file? it may be better ux if message is really big.
It can get messy if you have multiple input expecting a json, so to simplify things I'd say no.
If you want a better UX you break out the json in multiple inputs by using the feature added here
julienrbrt
added
the
backport/v0.52.x
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
client/v2/autocli/flag/messager_binder.go (2)
94-125: Enhance error messages by including the full field pathIncluding the full field path in error messages within the
bindNestedFieldfunction would provide better context for debugging when a field is not found.Consider updating the error message on line 104:
- return fmt.Errorf("field %q not found", path[0]) + return fmt.Errorf("field %q not found in path %q", path[0], strings.Join(path, "."))
Line range hint
301-301: Address the TODO by enhancing the error messageThe TODO comment suggests including
msg.Descriptor().FullName()in the error message to improve clarity. Implementing this change would provide more context about the message where the field is missing.Consider updating the error message on line 301:
- return fieldBinding{}, fmt.Errorf("can't find field %s", name) // TODO: it will improve error if msg.FullName() was included.` + return fieldBinding{}, fmt.Errorf("can't find field %s in message %s", name, msg.Descriptor().FullName())Would you like me to open a GitHub issue for this enhancement?
client/v2/autocli/flag/builder.go (1)
276-294: Consider renaming variablestofieldPathSegmentsfor clarityIn the
addFlattenFieldBindingToArgsfunction, renaming the variablestofieldPathSegmentswould improve readability by making the purpose of the variable clearer.Apply this diff to rename the variable:
- func (b *Builder) addFlattenFieldBindingToArgs(ctx *context.Context, path string, s []string, msg protoreflect.MessageType, messageBinder *MessageBinder) error { + func (b *Builder) addFlattenFieldBindingToArgs(ctx *context.Context, path string, fieldPathSegments []string, msg protoreflect.MessageType, messageBinder *MessageBinder) error { // update usages of 's' within the function - if len(s) == 1 { + if len(fieldPathSegments) == 1 { - fd := fields.ByName(protoreflect.Name(s[0])) + fd := fields.ByName(protoreflect.Name(fieldPathSegments[0])) - return b.addFlattenFieldBindingToArgs(ctx, path, s[1:], innerMsg, messageBinder) + return b.addFlattenFieldBindingToArgs(ctx, path, fieldPathSegments[1:], innerMsg, messageBinder)client/v2/CHANGELOG.md (1)
49-49: Ensure consistent capitalization of 'AutoCLI'For consistency, 'autocli' should be capitalized as 'AutoCLI' to match the project's naming convention.
Apply this diff to correct the capitalization:
- * [#22890](https://github.com/cosmos/cosmos-sdk/pull/22890) Added support for flattening inner message fields in autocli as positional arguments. + * [#22890](https://github.com/cosmos/cosmos-sdk/pull/22890) Added support for flattening inner message fields in AutoCLI as positional arguments.client/v2/autocli/msg_test.go (1)
131-156: Enhance test coverage for flattened fields.While the test validates the basic functionality of flattened fields, consider adding the following test cases:
- Invalid input validation (e.g., missing required fields)
- Error cases (e.g., malformed nested field paths)
- Edge cases (e.g., deeply nested fields, multiple array indices)
Add test cases for error scenarios:
func TestMsgWithFlattenFields(t *testing.T) { fixture := initFixture(t) + + // Test happy path out, err := runCmd(fixture, buildCustomModuleMsgCommand(&autocliv1.ServiceCommandDescriptor{ Service: bankv1beta1.Msg_ServiceDesc.ServiceName, RpcCommandOptions: []*autocliv1.RpcCommandOptions{ { RpcMethod: "UpdateParams", PositionalArgs: []*autocliv1.PositionalArgDescriptor{ {ProtoField: "authority"}, {ProtoField: "params.send_enabled.denom"}, {ProtoField: "params.send_enabled.enabled"}, {ProtoField: "params.default_send_enabled"}, }, }, }, EnhanceCustomCommand: true, }), "update-params", "cosmos1y74p8wyy4enfhfn342njve6cjmj5c8dtl6emdk", "stake", "true", "true", "--generate-only", "--output", "json", "--chain-id", fixture.chainID, ) assert.NilError(t, err) assertNormalizedJSONEqual(t, out.Bytes(), goldenLoad(t, "flatten-output.golden")) + + // Test invalid nested field path + _, err = runCmd(fixture, buildCustomModuleMsgCommand(&autocliv1.ServiceCommandDescriptor{ + Service: bankv1beta1.Msg_ServiceDesc.ServiceName, + RpcCommandOptions: []*autocliv1.RpcCommandOptions{ + { + RpcMethod: "UpdateParams", + PositionalArgs: []*autocliv1.PositionalArgDescriptor{ + {ProtoField: "params.invalid.path"}, + }, + }, + }, + }), "update-params", "value", + "--generate-only", + ) + assert.ErrorContains(t, err, "invalid field path") + + // Test missing required fields + _, err = runCmd(fixture, buildCustomModuleMsgCommand(&autocliv1.ServiceCommandDescriptor{ + Service: bankv1beta1.Msg_ServiceDesc.ServiceName, + RpcCommandOptions: []*autocliv1.RpcCommandOptions{ + { + RpcMethod: "UpdateParams", + PositionalArgs: []*autocliv1.PositionalArgDescriptor{ + {ProtoField: "params.send_enabled.denom"}, + }, + }, + }, + }), "update-params", "stake", + "--generate-only", + ) + assert.ErrorContains(t, err, "missing required field") }api/cosmos/benchmark/module/v1/module.pulsar.go (1)
1364-1384: Enhance field documentation with units and valid ranges.The documentation is clear but could be more helpful by including:
- Units for numeric fields (e.g., bytes for sizes)
- Valid value ranges
- Examples of typical values
Example improvements for selected fields:
- // key_mean is the mean size (in normal distribution) of keys in each bucket. + // key_mean is the mean size in bytes (in normal distribution) of keys in each bucket. + // Valid range: 1-1024. Typical value: 32. KeyMean uint64 `protobuf:"varint,3,opt,name=key_mean,json=keyMean,proto3" json:"key_mean,omitempty"` - // insert_weight is the weight of insert operations. + // insert_weight is the weight of insert operations. + // Valid range: 0.0-1.0. The sum of all weights should equal 1.0. + // Example: 0.25 means 25% of operations will be inserts. InsertWeight float32 `protobuf:"fixed32,9,opt,name=insert_weight,json=insertWeight,proto3" json:"insert_weight,omitempty"`
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
api/cosmos/benchmark/module/v1/module.pulsar.go(1 hunks)client/v2/CHANGELOG.md(1 hunks)client/v2/autocli/flag/builder.go(3 hunks)client/v2/autocli/flag/messager_binder.go(4 hunks)client/v2/autocli/msg_test.go(1 hunks)client/v2/autocli/testdata/flatten-output.golden(1 hunks)proto/cosmos/autocli/v1/options.proto(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- client/v2/autocli/testdata/flatten-output.golden
🧰 Additional context used
📓 Path-based instructions (5)
client/v2/autocli/msg_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/autocli/flag/messager_binder.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
client/v2/autocli/flag/builder.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
client/v2/CHANGELOG.md (1)
Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
api/cosmos/benchmark/module/v1/module.pulsar.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
🔇 Additional comments (4)
client/v2/autocli/flag/builder.go (1)
301-301: Address the TODO by enhancing the error message
The TODO comment suggests including msg.FullName() in the error message for better clarity. Implementing this would provide additional context when a field cannot be found.
Consider updating the error message on line 301:
- return fieldBinding{}, fmt.Errorf("can't find field %s", name) // TODO: it will improve error if msg.FullName() was included.`
+ return fieldBinding{}, fmt.Errorf("can't find field %s in message %s", name, msg.FullName())Would you like me to open a GitHub issue for this enhancement?
proto/cosmos/autocli/v1/options.proto (2)
6-6: LGTM!
The addition of the go_package option aligns with best practices for Go code generation from proto files.
Line range hint 79-79: Ensure correct syntax for field annotations
The annotation for gov_proposal on line 79 appears correct. Just double-check that the version string matches the intended release.
🧰 Tools
🪛 buf (1.47.2)
5-5: import "cosmos_proto/cosmos.proto": file does not exist
(COMPILE)
client/v2/CHANGELOG.md (1)
Line range hint 69-69: Correct the capitalization of 'GitHub'
In the usage instructions, 'Github' should be capitalized as 'GitHub' to reflect the proper branding.
Apply this diff:
- The issue numbers will later be link-ified during the release process so you do
- not have to worry about including a link manually, but you can if you wish.
+ The issue numbers will later be link-ified during the release process so you do
+ not have to worry about including a link manually, but you can if you wish.Note: It seems there is already correct capitalization, so please disregard if 'GitHub' is already properly capitalized.
$ simd tx circuit authorize alice super-admin "/cosmos.bank.v1beta1.MsgSend,/cosmos.bank.v1beta1.MsgMultiSend"
...
messages:
- '@type': /cosmos.circuit.v1.MsgAuthorizeCircuitBreaker
grantee: alice
granter: cosmos1r7e7rme2mrqdvju2qxtgcxp3f0ckevyj9p3e76
permissions:
level: LEVEL_SUPER_ADMIN
limit_type_urls:
- /cosmos.bank.v1beta1.MsgSend
- /cosmos.bank.v1beta1.MsgMultiSend
...diff --git a/x/circuit/autocli.go b/x/circuit/autocli.go
index a1cb8ada74..2d45d28072 100644
--- a/x/circuit/autocli.go
+++ b/x/circuit/autocli.go
@@ -37,16 +37,14 @@ func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions {
RpcCommandOptions: []*autocliv1.RpcCommandOptions{
{
RpcMethod: "AuthorizeCircuitBreaker",
- Use: "authorize <grantee> <permissions_json> --from <granter>",
+ Use: "authorize <grantee> <level> <msg_type_urls> --from <granter>",
Short: "Authorize an account to trip the circuit breaker.",
- Long: `Authorize an account to trip the circuit breaker.
-"SOME_MSGS" = 1,
-"ALL_MSGS" = 2,
-"SUPER_ADMIN" = 3,`,
- Example: fmt.Sprintf(`%s tx circuit authorize [address] '{"level":1,"limit_type_urls":["/cosmos.bank.v1beta1.MsgSend", "/cosmos.bank.v1beta1.MsgMultiSend"]}'"`, version.AppName),
+ Long: `Authorize an account to trip the circuit breaker. Level can be: some-msgs, all-msgs or super-admin.`,
+ Example: fmt.Sprintf(`%s tx circuit authorize [address] super-admin "/cosmos.bank.v1beta1.MsgSend, /cosmos.bank.v1beta1.MsgMultiSend"`, version.AppName),
PositionalArgs: []*autocliv1.PositionalArgDescriptor{
{ProtoField: "grantee"},
- {ProtoField: "permissions"}, // TODO(@julienrbrt) Support flattening msg for setting each field as a positional arg
+ {ProtoField: "permissions.level"},
+ {ProtoField: "permissions.limit_type_urls"},
},
},
{ |
There was a problem hiding this comment.
Let's add some docs about it in the README as well please. Can we maybe add flag support in a follow-up?
So that this can work for instance:
PositionalArgs: []*autocliv1.PositionalArgDescriptor{
{ProtoField: "grantee"},
{ProtoField: "permissions.limit_type_urls"},
},
FlagOptions: map[string]*autocliv1.FlagOptions{
"permissions.level": {Name: "level", DefaultValue: "some-msgs"},
},
JulianToledano
requested review from
kocubinski,
akhilkumarpilli and
raynaudoe
as code owners
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
client/v2/README.md (3)
173-176: Consider adding field descriptions in the protobuf example.While the protobuf messages are well-structured, adding comments to describe the purpose of each field would improve clarity:
message Permissions { + // level defines the permission level (e.g., "super-admin", "some-msgs") string level = 1; + // limit_type_urls defines the list of message type URLs that the grantee can manage repeated string limit_type_urls = 2; }
186-196: Consider adding explanatory comments to the AutoCLI configuration.The configuration example would be more educational with inline comments explaining each option:
{ RpcMethod: "AuthorizeCircuitBreaker", + // Define command usage with clear parameter descriptions Use: "authorize <grantee> <level> <msg_type_urls>", PositionalArgs: []*autocliv1.PositionalArgDescriptor{ + // Map grantee address to the first position {ProtoField: "grantee"}, + // Map nested permission level to the second position {ProtoField: "permissions.level"}, + // Map nested type URLs to the third position {ProtoField: "permissions.limit_type_urls"}, }, }
198-204: Consider adding a comparison with the non-flattened alternative.To better illustrate the benefits, show how the same command would look without flattening:
This allows users to provide values for nested fields directly as positional arguments: ```bash <appd> tx circuit authorize cosmos1... super-admin "/cosmos.bank.v1beta1.MsgSend,/cosmos.bank.v1beta1.MsgMultiSend"+Without flattening, users would need to provide a JSON structure:
+bash +<appd> tx circuit authorize cosmos1... '{"level":"super-admin","limit_type_urls":["/cosmos.bank.v1beta1.MsgSend","/cosmos.bank.v1beta1.MsgMultiSend"]}' +</blockquote></details> <details> <summary>x/circuit/autocli.go (1)</summary><blockquote> `40-40`: **LGTM! Consider making the example more generic.** The command structure and documentation are clear and well-organized. However, the example uses specific message types that might become outdated. Consider using placeholder text to make the example more maintainable: ```diff -Example: fmt.Sprintf(`%s tx circuit authorize [address] super-admin "/cosmos.bank.v1beta1.MsgSend,/cosmos.bank.v1beta1.MsgMultiSend"`, version.AppName), +Example: fmt.Sprintf(`%s tx circuit authorize [address] super-admin "[msg-type-url-1],[msg-type-url-2]"`, version.AppName),Also applies to: 42-43
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
client/v2/README.md(1 hunks)x/circuit/autocli.go(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
x/circuit/autocli.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
client/v2/README.md (1)
Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
🔇 Additional comments (2)
client/v2/README.md (1)
164-169: LGTM! Clear and well-structured introduction.
The section header and introduction effectively explain the concept of flattened fields in positional arguments.
x/circuit/autocli.go (1)
46-48: Verify the necessity of both parent and nested permission fields.
The positional arguments include both the parent permissions field and its nested fields (level and limit_type_urls). This structure might cause confusion about how to provide these arguments.
Let's check how these fields are used in the codebase:
✅ Verification successful
Let me gather more information about how these fields are used in the actual implementation.
Let me search for more specific information about the flattening configuration.
Let me check one more thing about the CLI command implementation and its usage.
Based on the gathered information, I can now provide a final response about the positional arguments configuration.
The parent and nested permission fields are correctly configured
The configuration is intentional and matches the CLI command's usage pattern. This is evidenced by:
- The example command shows the expected usage:
tx circuit authorize [address] super-admin "/cosmos.bank.v1beta1.MsgSend,/cosmos.bank.v1beta1.MsgMultiSend"
- The positional arguments match this pattern:
granteefor the addresspermissions.levelfor the admin levelpermissions.limit_type_urlsfor the message types
The parent permissions field is included to maintain the proper message structure, while the nested fields are flattened for CLI usability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of these fields in message definitions and tests
ast-grep --pattern 'message Permissions {
$$$
Level level = $_;
repeated string limit_type_urls = $_;
$$$
}'
# Search for related test cases
rg -A 5 'TestAuthorizeCircuitBreaker|TestMsgWithFlattenFields'
Length of output: 1482
Script:
#!/bin/bash
# Search for the message definition and its usage
rg -A 10 "message MsgAuthorizeCircuitBreaker"
# Search for any flattened field configurations
rg -B 2 -A 2 "FlattenOptions|flatten:"
# Look for CLI command implementations
ast-grep --pattern 'func NewMsgAuthorizeCircuitBreakerCmd() *cobra.Command {
$$$
}'
Length of output: 67790
Script:
#!/bin/bash
# Search for flattening configuration in autocli
rg -B 2 -A 2 'FlattenOptions|flatten:' x/circuit/
# Search for the Permissions message definition
ast-grep --pattern 'message Permissions {
$$$
}'
# Look for any CLI command implementations that use these fields
rg -A 5 'permissions.level|permissions.limit_type_urls' x/circuit/
Length of output: 514
Script:
#!/bin/bash
# Search for the CLI command usage and examples
rg -A 10 'Example:|Usage:' x/circuit/
# Look for test cases that demonstrate the field usage
rg -A 10 'TestCmd|TestAuthorize.*Circuit' x/circuit/
# Check if there are any comments about flattening in the code
rg -B 2 'permissions.*{' x/circuit/
Length of output: 5345
|
Can you update the system tests to match the new command? |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
tests/systemtests/circuit_test.go (1)
133-133: Consider adding negative test casesWhile the happy path is well tested, consider adding test cases for:
- Invalid permission levels
- Malformed message type URLs
- Empty message type URLs list when required
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
tests/systemtests/circuit_test.go(1 hunks)x/circuit/autocli.go(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
x/circuit/autocli.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
tests/systemtests/circuit_test.go (3)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern tests/**/*: "Assess the integration and e2e test code assessing sufficient code coverage for the changes associated in the pull request"
Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"
🔇 Additional comments (3)
x/circuit/autocli.go (2)
40-40: Improved CLI command structure and documentation
The command structure has been simplified and made more intuitive by:
- Replacing JSON input with clear positional arguments
- Adding explicit documentation for permission levels
- Providing a more straightforward example
Also applies to: 42-43
46-47: Verify backward compatibility of the new command structure
While the new positional arguments improve usability, we should ensure existing scripts using the old JSON format are properly handled.
✅ Verification successful
Based on the extensive codebase analysis, I can now provide a definitive response regarding the backward compatibility concern:
No backward compatibility concerns with the new command structure
The circuit authorize command's new positional arguments structure is safe to implement because:
- There are no existing shell scripts in the codebase using the old JSON format for the circuit authorize command
- The AutoCLI documentation explicitly shows this is a new feature for flattening nested message fields as positional arguments
- The underlying protobuf message structure remains unchanged, so any existing programmatic usage would continue to work
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing usage of the circuit authorize command in scripts
rg -g '*.{sh,bash,zsh}' 'circuit.*authorize.*permissions'
Length of output: 59
Script:
#!/bin/bash
# Let's search for any test files or documentation that might show usage examples
rg -g '*.{go,md}' -i 'circuit.*authorize.*permissions'
# Also search for any CLI tests specifically
fd -e go test.*cli -x rg -l 'circuit.*authorize'
# Look for any existing circuit authorization related code
ast-grep --pattern 'func $_($$$ *cobra.Command $$$) {
$$$
authorize $$$
}'
Length of output: 1082
Script:
#!/bin/bash
# Let's check for any existing CLI tests specifically for circuit authorization
rg -g '*.go' -B 5 -A 5 'TestCmd.*Circuit.*Authorize'
# Look for any examples or documentation of the command usage
fd -e md -x rg -l 'circuit.*authorize'
# Check the actual CLI command implementation
ast-grep --pattern 'func NewAuthorizeCommand() *cobra.Command {
$$$
}'
Length of output: 192
Script:
#!/bin/bash
# Let's check the content of the README that mentions circuit authorize
cat ./client/v2/README.md
# Let's also check for any recent changes to circuit authorization related files
rg -g '*.go' -B 3 -A 3 'MsgAuthorizeCircuitBreaker'
Length of output: 96488
tests/systemtests/circuit_test.go (1)
104-104: Enhanced test readability with descriptive permission levels
The change from numeric to string-based permission levels improves code readability and maintainability. The values now directly correspond to the CLI documentation.
Also applies to: 111-111, 118-118, 125-125
(cherry picked from commit cb56c6e)
…) (#22980) Co-authored-by: Julián Toledano <[email protected]>
…) (#22980) Co-authored-by: Julián Toledano <[email protected]>
Description
Closes: #18310
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
GeneratorParamsstruct fields.Bug Fixes
*big.Intunmarshalling in transactions.Documentation
client/v2with new features, improvements, and breaking changes.autocli, detailing usage of flattened fields in positional arguments.Tests
TestMsgWithFlattenFieldsto validate command execution.Chores
flatten-output.goldenfor parameter updates.