Merge branch 'main' into feat/display-mnemonic-discreetly

.github/workflows/stale.yml

@@ -13,7 +13,7 @@ jobs:
       pull-requests: write  # for actions/stale to close stale PRs
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@v8
+      - uses: actions/stale@v9
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
           stale-pr-message: "This pull request has been automatically marked as stale because it has not had

CHANGELOG.md

@@ -57,6 +57,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 ### Improvements
 
 * (client/keys) [#18663](https://github.com/cosmos/cosmos-sdk/pull/18663) Improve `<appd> keys add` by displaying mnemonic discreetly on an alternate screen and adding `--indiscreet` option to disable it.
+* (telemetry) [#18646] (https://github.com/cosmos/cosmos-sdk/pull/18646) Enable statsd and dogstatsd telemetry sinks
 * (types) [#18440](https://github.com/cosmos/cosmos-sdk/pull/18440) Add `AmountOfNoValidation` to `sdk.DecCoins`.
 * (x/gov) [#18025](https://github.com/cosmos/cosmos-sdk/pull/18025) Improve `<appd> q gov proposer` by querying directly a proposal instead of tx events. It is an alias of `q gov proposal` as the proposer is a field of the proposal.
 * (client) [#17503](https://github.com/cosmos/cosmos-sdk/pull/17503) Add `client.Context{}.WithAddressCodec`, `WithValidatorAddressCodec`, `WithConsensusAddressCodec` to provide address codecs to the client context. See the [UPGRADING.md](./UPGRADING.md) for more details.
@@ -85,6 +86,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (simulation) [#17911](https://github.com/cosmos/cosmos-sdk/pull/17911) Fix all problems with executing command `make test-sim-custom-genesis-fast` for simulation test.
 * (simulation) [#18196](https://github.com/cosmos/cosmos-sdk/pull/18196) Fix the problem of `validator set is empty after InitGenesis` in simulation test.
 * (baseapp) [#18551](https://github.com/cosmos/cosmos-sdk/pull/18551) Fix SelectTxForProposal the calculation method of tx bytes size is inconsistent with CometBFT
+* (baseapp) [#18654](https://github.com/cosmos/cosmos-sdk/pull/18654) Fixes an issue in which gogoproto.Merge does not work with gogoproto messages with custom types.
 
 ### API Breaking Changes
 

baseapp/internal/protocompat/protocompat.go

@@ -6,6 +6,7 @@ import (
 	"reflect"
 
 	gogoproto "github.com/cosmos/gogoproto/proto"
+	"github.com/golang/protobuf/proto" // nolint: staticcheck // needed because gogoproto.Merge does not work consistently. See NOTE: comments.
 	"google.golang.org/grpc"
 	proto2 "google.golang.org/protobuf/proto"
 	"google.golang.org/protobuf/reflect/protoreflect"
@@ -125,14 +126,18 @@ func makeGogoHybridHandler(prefMethod protoreflect.MethodDescriptor, cdc codec.B
 			}
 			resp, err := method.Handler(handler, ctx, func(msg any) error {
 				// merge! ref: https://github.com/cosmos/cosmos-sdk/issues/18003
-				gogoproto.Merge(msg.(gogoproto.Message), inReq)
+				// NOTE: using gogoproto.Merge will fail for some reason unknown to me, but
+				// using proto.Merge with gogo messages seems to work fine.
+				proto.Merge(msg.(gogoproto.Message), inReq)
 				return nil
 			}, nil)
 			if err != nil {
 				return err
 			}
 			// merge resp, ref: https://github.com/cosmos/cosmos-sdk/issues/18003
-			gogoproto.Merge(outResp.(gogoproto.Message), resp.(gogoproto.Message))
+			// NOTE: using gogoproto.Merge will fail for some reason unknown to me, but
+			// using proto.Merge with gogo messages seems to work fine.
+			proto.Merge(outResp.(gogoproto.Message), resp.(gogoproto.Message))
 			return nil
 		}, nil
 	}
@@ -165,14 +170,19 @@ func makeGogoHybridHandler(prefMethod protoreflect.MethodDescriptor, cdc codec.B
 			// we can just call the handler after making a copy of the message, for safety reasons.
 			resp, err := method.Handler(handler, ctx, func(msg any) error {
 				// ref: https://github.com/cosmos/cosmos-sdk/issues/18003
-				gogoproto.Merge(msg.(gogoproto.Message), m)
+				asGogoProto := msg.(gogoproto.Message)
+				// NOTE: using gogoproto.Merge will fail for some reason unknown to me, but
+				// using proto.Merge with gogo messages seems to work fine.
+				proto.Merge(asGogoProto, m)
 				return nil
 			}, nil)
 			if err != nil {
 				return err
 			}
 			// merge on the resp, ref: https://github.com/cosmos/cosmos-sdk/issues/18003
-			gogoproto.Merge(outResp.(gogoproto.Message), resp.(gogoproto.Message))
+			// NOTE: using gogoproto.Merge will fail for some reason unknown to me, but
+			// using proto.Merge with gogo messages seems to work fine.
+			proto.Merge(outResp.(gogoproto.Message), resp.(gogoproto.Message))
 			return nil
 		default:
 			panic("unreachable")

client/v2/README.md

@@ -37,7 +37,7 @@ It is possible to customize the generation of transactions and queries by defini
 Here are the steps to use AutoCLI:
 
 1. Ensure your app's modules implements the `appmodule.AppModule` interface.
-2. (optional) Configure how behave `autocli` command generation, by implementing the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module.
+2. (optional) Configure how to behave as `autocli` command generation, by implementing the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module.
 3. Use the `autocli.AppOptions` struct to specify the modules you defined. If you are using `depinject` / app v2, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration.
 4. Use the `EnhanceRootCommand()` method provided by `autocli` to add the CLI commands for the specified modules to your root command.
 
@@ -211,7 +211,7 @@ https://github.com/cosmos/cosmos-sdk/blob/main/client/grpc/cmtservice/autocli.go
 
 ## Summary
 
-`autocli` let you generate CLI to your Cosmos SDK-based applications without any cobra boilerplate. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application.
+`autocli` lets you generate CLI to your Cosmos SDK-based applications without any cobra boilerplate. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application.
 
 To further enhance your CLI experience with Cosmos SDK-based blockchains, you can use `hubl`. `hubl` is a tool that allows you to query any Cosmos SDK-based blockchain using the new AutoCLI feature of the Cosmos SDK. With `hubl`, you can easily configure a new chain and query modules with just a few simple commands.
 

client/v2/go.mod

@@ -33,7 +33,9 @@ require (
 	filippo.io/edwards25519 v1.0.0 // indirect
 	github.com/99designs/go-keychain v0.0.0-20191008050251-8e49817e8af4 // indirect
 	github.com/99designs/keyring v1.2.1 // indirect
+	github.com/DataDog/datadog-go v4.8.3+incompatible // indirect
 	github.com/DataDog/zstd v1.5.5 // indirect
+	github.com/Microsoft/go-winio v0.6.0 // indirect
 	github.com/beorn7/perks v1.0.1 // indirect
 	github.com/bgentry/speakeasy v0.1.1-0.20220910012023-760eaf8b6816 // indirect
 	github.com/btcsuite/btcd/btcec/v2 v2.3.2 // indirect
@@ -148,11 +150,13 @@ require (
 	go.uber.org/multierr v1.11.0 // indirect
 	golang.org/x/crypto v0.16.0 // indirect
 	golang.org/x/exp v0.0.0-20231127185646-65229373498e // indirect
+	golang.org/x/mod v0.14.0 // indirect
 	golang.org/x/net v0.19.0 // indirect
 	golang.org/x/sync v0.5.0 // indirect
 	golang.org/x/sys v0.15.0 // indirect
 	golang.org/x/term v0.15.0 // indirect
 	golang.org/x/text v0.14.0 // indirect
+	golang.org/x/tools v0.16.0 // indirect
 	google.golang.org/genproto v0.0.0-20231120223509-83a465c0220f // indirect
 	google.golang.org/genproto/googleapis/api v0.0.0-20231106174013-bbf56f31fb17 // indirect
 	google.golang.org/genproto/googleapis/rpc v0.0.0-20231127180814-3a041ad873d4 // indirect

client/v2/go.sum

@@ -65,6 +65,8 @@ github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161/go.mod h1:xomTg6
 github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
 github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
 github.com/DataDog/datadog-go v3.2.0+incompatible/go.mod h1:LButxg5PwREeZtORoXG3tL4fMGNddJ+vMq1mwgfaqoQ=
+github.com/DataDog/datadog-go v4.8.3+incompatible h1:fNGaYSuObuQb5nzeTQqowRAd9bpDIRRV4/gUtIBjh8Q=
+github.com/DataDog/datadog-go v4.8.3+incompatible/go.mod h1:LButxg5PwREeZtORoXG3tL4fMGNddJ+vMq1mwgfaqoQ=
 github.com/DataDog/zstd v1.5.5 h1:oWf5W7GtOLgp6bciQYDmhHHjdhYkALu6S/5Ni9ZgSvQ=
 github.com/DataDog/zstd v1.5.5/go.mod h1:g4AWEaM3yOg3HYfnJ3YIawPnVdXJh9QME85blwSAmyw=
 github.com/Knetic/govaluate v3.0.1-0.20171022003610-9aa49832a739+incompatible/go.mod h1:r7JcOSlj0wfOMncg0iLm8Leh48TZaKVeNIfJntJ2wa0=

codec/unknownproto/unknown_fields.go

@@ -44,12 +44,7 @@ func RejectUnknownFields(bz []byte, msg proto.Message, allowUnknownNonCriticals
 		return hasUnknownNonCriticals, nil
 	}
 
-	desc, ok := msg.(descriptorIface)
-	if !ok {
-		return hasUnknownNonCriticals, fmt.Errorf("%T does not have a Descriptor() method", msg)
-	}
-
-	fieldDescProtoFromTagNum, _, err := getDescriptorInfo(desc, msg)
+	fieldDescProtoFromTagNum, _, err := getDescriptorInfo(msg)
 	if err != nil {
 		return hasUnknownNonCriticals, err
 	}
@@ -345,7 +340,11 @@ func unnestDesc(mdescs []*descriptorpb.DescriptorProto, indices []int) *descript
 
 // Invoking descriptorpb.ForMessage(proto.Message.(Descriptor).Descriptor()) is incredibly slow
 // for every single message, thus the need for a hand-rolled custom version that's performant and cacheable.
-func extractFileDescMessageDesc(desc descriptorIface) (*descriptorpb.FileDescriptorProto, *descriptorpb.DescriptorProto, error) {
+func extractFileDescMessageDesc(msg proto.Message) (*descriptorpb.FileDescriptorProto, *descriptorpb.DescriptorProto, error) {
+	desc, ok := msg.(descriptorIface)
+	if !ok {
+		return nil, nil, fmt.Errorf("%T does not have a Descriptor() method", msg)
+	}
 	gzippedPb, indices := desc.Descriptor()
 
 	protoFileToDescMu.RLock()
@@ -391,7 +390,8 @@ var (
 )
 
 // getDescriptorInfo retrieves the mapping of field numbers to their respective field descriptors.
-func getDescriptorInfo(desc descriptorIface, msg proto.Message) (map[int32]*descriptorpb.FieldDescriptorProto, *descriptorpb.DescriptorProto, error) {
+func getDescriptorInfo(msg proto.Message) (map[int32]*descriptorpb.FieldDescriptorProto, *descriptorpb.DescriptorProto, error) {
+	// we immediately check if the desc is present in the desc
 	key := reflect.ValueOf(msg).Type()
 
 	descprotoCacheMu.RLock()
@@ -403,7 +403,7 @@ func getDescriptorInfo(desc descriptorIface, msg proto.Message) (map[int32]*desc
 	}
 
 	// Now compute and cache the index.
-	_, md, err := extractFileDescMessageDesc(desc)
+	_, md, err := extractFileDescMessageDesc(msg)
 	if err != nil {
 		return nil, nil, err
 	}

docs/architecture/adr-050-sign-mode-textual-annex2.md

@@ -25,7 +25,7 @@ Unicode text within the transaction.
 
 `SIGN_MODE_TEXTUAL` renders to an abstract representation, leaving it
 up to device-specific software how to present this representation given the
-capabilities, limitations, and conventions of the deivce.
+capabilities, limitations, and conventions of the device.
 
 We offer the following normative guidance:
 
@@ -77,7 +77,7 @@ in many languages:
 * All other ASCII control characters, plus non-ASCII Unicode code points,
 are shown as either:
 
-    * `\u` followed by 4 uppercase hex chacters for code points
+    * `\u` followed by 4 uppercase hex characters for code points
     in the basic multilingual plane (BMP).
 
     * `\U` followed by 8 uppercase hex characters for other code points.
@@ -116,7 +116,7 @@ Indent  Text
 0       ">tricky key4<: note the leading space in the presentation"
 0       "introducing an aggregate"
 1       "key5: false"
-1       "key6: a very long line of text, please coöperate and break into multiple lines."
+1       "key6: a very long line of text, please cooperate and break into multiple lines."
 1       "Can we do further nesting?"
 2       "You bet we can!"
 ```

docs/architecture/adr-061-liquid-staking.md

@@ -20,7 +20,7 @@ As both Proof of Stake and blockchain use cases have matured, this design has ag
 
 The most important deficiency of the legacy staking design is that it composes poorly with on chain protocols for trading, lending, derivatives that are referred to collectively as DeFi. The legacy staking implementation starves these applications of liquidity by increasing the risk free rate adaptively. It basically makes DeFi and staking security somewhat incompatible. 
 
-The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi appliactions can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK.
+The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi applications can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK.
 
 It's also important to note that Interchain Accounts are available in the default IBC implementation and can be used to [rehypothecate](https://www.investopedia.com/terms/h/hypothecation.asp#toc-what-is-rehypothecation) delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. 
 

docs/architecture/adr-063-core-module-api.md

@@ -282,7 +282,7 @@ type HasGenesis interface {
 
 #### Pre Blockers
 
-Modules that have functionality that runs before BeginBlock and should implement the has `HasPreBlocker` interfaces:
+Modules that have functionality that runs before BeginBlock and should implement the `HasPreBlocker` interfaces:
 
 ```go
 type HasPreBlocker interface {
@@ -294,7 +294,7 @@ type HasPreBlocker interface {
 #### Begin and End Blockers
 
 Modules that have functionality that runs before transactions (begin blockers) or after transactions
-(end blockers) should implement the has `HasBeginBlocker` and/or `HasEndBlocker` interfaces:
+(end blockers) should implement the `HasBeginBlocker` and/or `HasEndBlocker` interfaces:
 
 ```go
 type HasBeginBlocker interface {
@@ -452,7 +452,7 @@ func ProvideApp(config *foomodulev2.Module, evtSvc event.EventService, db orm.Mo
 The `core` module will define a static integer var, `cosmossdk.io/core.RuntimeCompatibilityVersion`, which is
 a minor version indicator of the core module that is accessible at runtime. Correct runtime module implementations
 should check this compatibility version and return an error if the current `RuntimeCompatibilityVersion` is higher
-than the version of the core API that this runtime version can support. When new features are adding to the `core`
+than the version of the core API that this runtime version can support. When new features are added to the `core`
 module API that runtime modules are required to support, this version should be incremented.
 
 ### Runtime Modules

docs/architecture/adr-064-abci-2.0.md

@@ -25,7 +25,7 @@ includes `ExtendVote`, `VerifyVoteExtension` and `FinalizeBlock`.
 ABCI 2.0 continues the promised updates from ABCI++, specifically three additional
 ABCI methods that the application can implement in order to gain further control,
 insight and customization of the consensus process, unlocking many novel use-cases
-that previously not possible. We describe these three new methods below:
+that were previously not possible. We describe these three new methods below:
 
 ### `ExtendVote`
 

docs/architecture/adr-067-simulator-v2.md

@@ -137,7 +137,7 @@ func (s *Simulator) SimulateBlock() {
 }
 ```
 
-Note, some application do not define or need their own app-side mempool, so we
+Note, some applications do not define or need their own app-side mempool, so we
 propose that `SelectTxs` mimic CometBFT and just return FIFO-ordered transactions
 from an ad-hoc simulator mempool. In the case where an application does define
 its own mempool, it will simply ignore what is provided in `RequestPrepareProposal`.
@@ -162,7 +162,7 @@ set of validity predicates, i.e. invariant checkers, that will be executed befor
 and after each block. This will allow for the application to assert that certain
 state invariants are held before and after each block. Note, as a consequence of
 this, we propose to remove the existing notion of invariants from module production
-execution paths and deprecate their usage all together.
+execution paths and deprecate their usage altogether.
 
 ```go
 type Manager struct {

docs/architecture/adr-069-gov-improvements.md

@@ -19,7 +19,7 @@ Those two types are, namely: multiple choice proposals and optimistic proposals.
 ## Context
 
 `x/gov` is the center of Cosmos governance, and has already been improved from its first version `v1beta1`, with a second version [`v1`][5].
-This second iteration on gov unlocked many possibilities by letting governance proposals contain any number of proposals.
+This second iteration of gov unlocked many possibilities by letting governance proposals contain any number of proposals.
 The last addition of gov has been expedited proposals (proposals that have a shorter voting period and a higher quorum, approval threshold).
 
 The community requested ([1], [4]) two additional proposals for improving governance choices. Those proposals would be useful when having protocol decisions made on specific choices or simplifying regular proposals that do not require high community involvement.
@@ -66,7 +66,7 @@ Voter can only vote NO on the proposal. If the NO threshold is reached, the opti
 Two governance parameters will be in added [`v1.Params`][5] to support optimistic proposals:
 
 ```protobuf
-// optimistic_authorized_addreses is an optional governance parameter that limits the authorized accounts than can submit optimisitc proposals
+// optimistic_authorized_addreses is an optional governance parameter that limits the authorized accounts that can submit optimistic proposals
 repeated string optimistic_authorized_addreses = 17 [(cosmos_proto.scalar) = "cosmos.AddressString"];
 
 // Optimistic rejected threshold defines at which percentage of NO votes, the optimistic proposal should fail and be converted to a standard proposal.
@@ -77,8 +77,8 @@ string optimistic_rejected_threshold = 18 [(cosmos_proto.scalar) = "cosmos.Dec"]
 
 A multiple choice proposal is a proposal where the voting options can be defined by the proposer.
 
-The number of voting option will be limited to a maximum of 4.
-A new vote option `SPAM` will be added and distinguished of those voting options. `SPAM` will be used to mark a proposal as spam and is explained further below.
+The number of voting options will be limited to a maximum of 4.
+A new vote option `SPAM` will be added and distinguished from those voting options. `SPAM` will be used to mark a proposal as spam and is explained further below.
 
 Multiple choice proposals, contrary to any other proposal type, cannot have messages to execute. They are only text proposals.
 

docs/spec/SPEC_MODULE.md

@@ -24,7 +24,7 @@ specifications for modules. The following list is nonbinding and all sections ar
 
 * `# {Module Name}` - overview of the module
 * `## Concepts` - describe specialized concepts and definitions used throughout the spec
-* `## State` - specify and describe structures expected to marshalled into the store, and their keys
+* `## State` - specify and describe structures expected to be marshalled into the store, and their keys
 * `## State Transitions` - standard state transition operations triggered by hooks, messages, etc.
 * `## Messages` - specify message structure(s) and expected state machine behaviour(s)
 * `## Begin Block` - specify any begin-block operations