You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If CustomGetSigners are added to the SigningOptions (that are provided to NewInterfaceRegistryWithOptions), they don't end up being conveyed to the result of NewTxConfig. That causes txConfig.SigningContext().Validate() to return an error for the protos that use a custom GetSigners method (and don't have a signer option): no cosmos.msg.v1.signer option found for message <msg name>; use DefineCustomGetSigners to specify a custom getter.
I would not expect to get an error there, though, since the interfaceRegistry and appCodec both handle the custom-get-signer stuff just fine. I.e. Neither interfaceRegistry.SigningContext().Validate() nor appCodec.InterfaceRegistry().SigningContext().Validate() returns an error.
A workaround is to use NewTxConfigWithOptions instead of NewTxConfig, and extract those signing options into its own variable so that they can be provided when creating both the interface registry and the tx-config. But I feel that NewTxConfig should get that info from the interface registry in the provided appCodec, and NewTxConfigWithOptions should too when the authtx.ConfigOptions.SigningOptions is nil (or maybe there's a more specific field to look at).
Cosmos SDK Version
v0.50.10
How to reproduce?
You'll need a proto with an endpoint that has a request message without a cosmos.msg.v1.signer option and a custom GetSigners function for it.
Add that info to the SigningOptions.CustomGetSigners map (e.g. using DefineCustomGetSigners) in the InterfaceRegistryOptions.SigningOptions that is provided to NewInterfaceRegistryWithOptions
When that runs, you'll get a panic because txConfig.SigningContext().Validate() will return an error: no cosmos.msg.v1.signer option found for message <msg name>; use DefineCustomGetSigners to specify a custom getter.
Then, later, after the bank keeper is made, to enable sign mode textual, you could just update txConfigOpts and give it to NewTxConfigWithOptions again.
But again, I feel like the custom GetSigners stuff should automatically get propagated from the interface registry in the appCodec to the txConfig without needing to also provide the signing options to NewTxConfigWithOptions.
The text was updated successfully, but these errors were encountered:
I think it is a valid point indeed. It was anyway a typo, as it should have been interfaceRegistry.SigningContext().Validate() instead of using txConfig, like we do in runtime, in the simapp app.go.
I would note that you don't need to do your workaround, as you can pass it directly in NewTxConfig, but your point remains valid, passing it twice, is not best:
julienrbrt
changed the title
NewTxConfig misses CustomGetSigners setup.
Signing options (e.g. CustomGetSigners) should be passed down to NewTxConfig
Oct 9, 2024
Is there an existing issue for this?
What happened?
The top of
NewSimApp
looks like this (inv0.50.10
):cosmos-sdk/simapp/app.go
Lines 197 to 214 in 6dc6e8b
If
CustomGetSigners
are added to theSigningOptions
(that are provided toNewInterfaceRegistryWithOptions
), they don't end up being conveyed to the result ofNewTxConfig
. That causestxConfig.SigningContext().Validate()
to return an error for the protos that use a customGetSigners
method (and don't have a signer option):no cosmos.msg.v1.signer option found for message <msg name>; use DefineCustomGetSigners to specify a custom getter
.I would not expect to get an error there, though, since the
interfaceRegistry
andappCodec
both handle the custom-get-signer stuff just fine. I.e. NeitherinterfaceRegistry.SigningContext().Validate()
norappCodec.InterfaceRegistry().SigningContext().Validate()
returns an error.A workaround is to use
NewTxConfigWithOptions
instead ofNewTxConfig
, and extract those signing options into its own variable so that they can be provided when creating both the interface registry and the tx-config. But I feel thatNewTxConfig
should get that info from the interface registry in the providedappCodec
, andNewTxConfigWithOptions
should too when theauthtx.ConfigOptions.SigningOptions
isnil
(or maybe there's a more specific field to look at).Cosmos SDK Version
v0.50.10
How to reproduce?
You'll need a proto with an endpoint that has a request message without a
cosmos.msg.v1.signer
option and a customGetSigners
function for it.Add that info to the
SigningOptions.CustomGetSigners
map (e.g. usingDefineCustomGetSigners
) in theInterfaceRegistryOptions.SigningOptions
that is provided toNewInterfaceRegistryWithOptions
Example code that panics:
When that runs, you'll get a panic because
txConfig.SigningContext().Validate()
will return an error:no cosmos.msg.v1.signer option found for message <msg name>; use DefineCustomGetSigners to specify a custom getter
.The workaround looks something like this:
Then, later, after the bank keeper is made, to enable sign mode textual, you could just update
txConfigOpts
and give it toNewTxConfigWithOptions
again.But again, I feel like the custom
GetSigners
stuff should automatically get propagated from the interface registry in theappCodec
to thetxConfig
without needing to also provide the signing options toNewTxConfigWithOptions
.The text was updated successfully, but these errors were encountered: