Upstream Go contributions to Cosmos SDK AutoCLI and IBC-Go

AutoCLI: the reported decoding failure

Cosmos SDK PR #24330 reported that AutoCLI commands for new modules failed to decode after a Go upgrade and removal of Pulsar from the application. AutoCLI builds command-line interfaces from protobuf descriptions. The reported diagnosis was that the interface registry, when used as a file resolver, could expose incomplete descriptors for a message also referenced within another message.

The PR used an AddressList message referenced by a Genesis message to illustrate the problem. Its diagnosis described placeholder descriptors and registration order: a command could encounter incomplete metadata for the type it needed to decode. The implementation addressed the resolver used during command construction, so the change belonged in the shared AutoCLI builder rather than in a specific module's generated commands.

Change the file resolver

The accepted patch called the gogoproto merged-registry function before constructing the AutoCLI builder. If registry construction failed, it returned the error. The resulting registry became the builder's FileResolver, while its TypeResolver remained the global type registry. A file resolver supplies protobuf file descriptors; in this change it was a distinct dependency from the resolver used for message types.

The change corrected the source of metadata at the command-building boundary instead of adding a workaround to individual generated commands. That kept the fix concentrated, but made registry construction an explicit failure point. Returning its error meant the builder would not continue with that registry unavailable. The distinction between file and type resolution also remained intact: the patch changed one dependency while preserving the other.

IBC-Go: inspecting a capability scope before creation

In IBC-Go PR #6716, I added HasModule(moduleName string) bool to the capability keeper. Its implementation checked whether the module name existed in the keeper's scopedModules map. A scoped keeper is the module-specific capability scope in this code. ScopeToModule's documentation states that creating a scope for an already scoped module causes a panic. The new helper exposed an existence check for application wiring before attempting that operation.

The added test created a scope for the bank module, asserted that HasModule returned true for it, and asserted false for an invalid module name. This establishes the behavior covered by that test and the deliberately narrow interface: callers can inspect scope existence. The contribution did not change ScopeToModule into an operation that silently reuses an existing scope.

The composition trade-off

A small query helper preserved the existing scope-creation contract while giving application code a way to avoid an accidental duplicate creation. Altering creation to reuse an existing scope would change a broader contract. With HasModule, the caller still decides how to handle an existing scope. The check alone does not provide a concurrency guarantee or prevent duplicate creation by callers that ignore it; its responsibility is reporting the keeper's current membership.

Contribution scope

The linked changes were merged upstream: IBC-Go #6716 in July 2024 and Cosmos SDK #24330 in April 2025. They document focused Go contributions to developer interfaces and module composition. One supplies a different metadata source for command construction; the other exposes state that callers need when wiring an application. Their scope is these accepted changes, rather than downstream deployment or network performance.