Add MsgInstantiateContractResponse.data

[webmaster128]

MsgExecuteContractResponse and MsgMigrateContractResponse have a contract defined data field. MsgInstantiateContractResponse does not have this for historic reasons (we returned the raw contract address before).

Now that we can easily return structured proto messages, it would be good to add MsgInstantiateContractResponse.data for consistency.

[ethanfrey]

Ah, so we can have both fields, sender address and contract data in the same response.

Yes, this makes sense. 👍 for being able to return structured data

[alpe]

Good 💡 The field is easy to add.

As a note: Instantiate can also be called by a gov proposal. The data field would not be returned or printed anywhere.
If there is a requirement for the data then the best we can do IMHO would be adding an attribute to the event.
WDYT? (This also affects migrate proposals) @webmaster128 @ethanfrey

[webmaster128]

As a note: Instantiate can also be called by a gov proposal. The data field would not be returned or printed anywhere.

How does this work for other message types that are executed as part of a gov proposal?

[ethanfrey]

Hmmm... it makes sense to return it as a hex/base64 encoded attribute as well.

The types allow you to pass in bytes but much code blindly converts to and from string, so let's keep it utf8

[webmaster128]

The types allow you to pass in bytes but much code blindly converts to and from string, so let's keep it utf8

This does not sound like a winning strategy. With the Stargate upgrade it is encouraged to store a serialized protobuf response in there, which is definitely not UTF8.

[alpe]

@webmaster128 do you have found an example or doc you can point me too?

[ethanfrey]

@webmaster128 @alpe Please read the discussion from here on: cosmos/cosmos-sdk#8624 (comment)

There was quite some discussion about using raw bytes in events

[alpe]

Thanks for the link! They ended up with hex encoded protobuf: cosmos/cosmos-sdk@cb28f10#diff-d2a466b18c54af68dfa1c635b309ebb1c5fe10f9c23fc99d89dcc83c95638ac6R103
Everybody ok with this? 👍 👎
It feels a bit odd to create a new proto type just for the byte data but 🤷

Next question would be to always store the data or only for operations not triggered by a client (gov/contracts) ?
Always would be easier to implement.

[ethanfrey]

Next question would be to always store the data or only for operations not triggered by a client (gov/contracts) ?
Always would be easier to implement.

I'd take the simpler route