Remove json type cast for contract msgs

[alpe]

Removes the cast type as it can cause some issues when unmarshaling from base64 encoded type. Better let the standardlib handle this.

[codecov]

Codecov Report

Merging #520 (98431c6) into master (4631658) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #520      +/-   ##
==========================================
+ Coverage   58.68%   58.71%   +0.03%     
==========================================
  Files          43       43              
  Lines        4504     4508       +4     
==========================================
+ Hits         2643     2647       +4     
  Misses       1644     1644              
  Partials      217      217              

Impacted Files	Coverage Δ
x/wasm/types/proposal.go	83.03% <100.00%> (+0.30%)	⬆️

[ethanfrey]

This cast was there for historical reasons. Pre-stargate, we had annoying strings like msg: "eyJmb28iOiJiYXIifQ==" in the output and we wanted msg: {"foo":"bar"}. Since both CLI and CosmJS queries went through the REST server which did the amino->JSON conversion in Go, this was needed.

@webmaster128 can correct me here if I am wrong, but I believe this change will have no impact on the cosmwasm-stargate package. It parsed protobuf byte field and manually converts it to a JSON object inside CosmJS. The GO casttype directive will have no impact.

The only other concern I have is the CLI query output. Can you check if this changes, and if it does, maybe a way to properly format/present this for such queries. Or will this only affect eg. block explorers?

if !json.Valid(p.InitMsg) is a nice check to provide better validity checks.

If there are no issues breaking the output to clients, I am very supportive of this change.

[webmaster128]

The gogoproto annotation does not change non-gogoproto code generation at all. So this is safe from my point of view.

The annotation was invalid and it is good that it is removed because the type json.RawMessage

is a raw encoded JSON value.

but we have no guerantee at all that the bytes sent are valid JSON. I.e. a simple cast is not good enough. If we needed that type, we had to do a validation followed by a cast.

[alpe]

The only other concern I have is the CLI query output. Can you check if this changes, and if it does, maybe a way to properly format/present this for such queries. Or will this only affect eg. block explorers?

The CLI is using the GRPC query endpoint only. We store the init message with the Code history entry as raw json entry. The CLI query for this works as before:

wasmd q wasm contract-history wasm10pyejy66429refv3g35g2t7am0was7yajwflk7 -o json | jq

{
  "entries": [
    {
      "operation": "CONTRACT_CODE_HISTORY_OPERATION_TYPE_INIT",
      "code_id": "2",
      "msg": {
        "verifier": "wasm1alz4eapgf0rq3ezf3xge9pz7uhkpdyu2mmrrup",
        "beneficiary": "wasm18t98u4xqa8zaq3ewfeq0u7yeee8cqc2sq9keek"
      }
    },
    {
      "operation": "CONTRACT_CODE_HISTORY_OPERATION_TYPE_MIGRATE",
      "code_id": "3",
      "msg": {
        "payout": "wasm18t98u4xqa8zaq3ewfeq0u7yeee8cqc2sq9keek"
      }
    }
  ],
  "pagination": {}
}

I have not tested the query with the legacy REST endpoint but I would not expect any differences as the history model has not changed.
I don't know how block explorer read the data but if they use the proto model to map a TX back to json representations then the init message is likely base64 encoded now

[ethanfrey]

Thanks for responding to my question. Good answer and happy to see this merged in.