feat: add separator to rpc block_results to identify msg & response pair

[r3v4s]

related to #2055

I'm opening this pr to get some ideas.

Currently, keeper does make response data with \n as separator to separate number of responses for single function.

gno/gno.land/pkg/sdk/vm/keeper.go

Lines 307 to 312 in 8057505

	for i, rtv := range rtvs {
	res = res + rtv.String()
	if i < len(rtvs)-1 {
	res += "\n"
	}
	}

If single function returns 2 string, response may look like this

("1" string)
("2" string)

However as describe in #2055, response for single tx with multi-msg really doesn't separate response values.

So this pr adds \n\n as a separator for every function.

sample contract

package returns

func FuncNo() {}

func Func2() (string, uint64) {
	return "asd", 123
}

func Func3() (int64, string, uint64) {
	return -1, "hmm", 78978
}

call with multi-msg

await adena.DoContract({
  messages: [
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "Func2",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "Func3",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    }
  ],
  gasFee: 1, 
  gasWanted: 2000000
});

block_results from rpc with b64 encoded

KCJhc2QiIHN0cmluZykKKDEyMyB1aW50NjQpKC0xIGludDY0KQooImhtbSIgc3RyaW5nKQooNzg5NzggdWludDY0KQ

b64 decoded

("asd" string)
(123 uint64)(-1 int64)
("hmm" string)
(78978 uint64)

two problem exists with above response

1. It needs to do something about function that doesn't return any value
2. It needs to divide results string for each function

in this pr response b64 encoded

CgooImFzZCIgc3RyaW5nKQooMTIzIHVpbnQ2NCkKCgoKKC0xIGludDY0KQooImhtbSIgc3RyaW5nKQooNzg5NzggdWludDY0KQoKCgo

decode b64 and divide by '\n\n'

From now, we know...

1. tx had 5 messages
2. first, third and fifth msg function doesn't return anything
3. second msg function return 2 values
4. fourth msg function return 3 values

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.19%. Comparing base (8057505) to head (054f323).
Report is 17 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2063      +/-   ##
==========================================
- Coverage   54.96%   54.19%   -0.77%     
==========================================
  Files         481      520      +39     
  Lines       67391    73195    +5804     
==========================================
+ Hits        37040    39668    +2628     
- Misses      27330    30300    +2970     
- Partials     3021     3227     +206     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[r3v4s]

@zivkovicmilos @leohhhn As we talked this pr does change rpc block_results response to identify msg & result pair.

But it doesn't cover custom return type such as type Blake struct.

Perhaps we can keep this pr open for historical, and find some better ways to resolve issue.

[zivkovicmilos]

I don't have a strong opinion on this, because I think that returning (<value> <type>) was not a good way to propagate realm responses in the first place to the user -- it makes it a nightmare for clients to:

• prepare calls
• parse responses

I honestly think the long term solution is #1842. However, I think this is a nice fix, so let's merge it 🚀

[ajnavarro]

I cannot agree with this is closing #2055 , but if we remove that trigger from this PR we can merge it as a small quality of life from people trying to know what is the output from a specific version.

[r3v4s]

I cannot agree with this is closing #2055 , but if we remove that trigger from this PR we can merge it as a small quality of life from people trying to know what is the output from a specific version.

Good point, just changed to related rather than closes