Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tx method on the rpc client fails with InvalidParams error #942

Closed
jstuczyn opened this issue Aug 6, 2021 · 7 comments · Fixed by #948
Closed

tx method on the rpc client fails with InvalidParams error #942

jstuczyn opened this issue Aug 6, 2021 · 7 comments · Fixed by #948
Assignees
Labels
bug Something isn't working rpc
Milestone

Comments

@jstuczyn
Copy link
Contributor

jstuczyn commented Aug 6, 2021

Hi! I've been trying to use the rpc client to search for transaction details by its hash (using the tx method), unfortunately it's been failing for me with the following error:

'called `Result::unwrap()` on an `Err` value: Error { code: InvalidParams, message: "Invalid params", data: Some("error converting json params to arguments: illegal base64 data at input byte 64") }'

In my tests I have used tendermint-rpc 0.21.0 run against wasmd 0.17 (https://github.com/CosmWasm/wasmd) based validators which under the hood use cosmos-sdk 0.42.5.

Steps to reproduce

  1. Start up a local (or could be remote for all it matters, I've checked it against both live and local instances) validator.

  2. Run the following piece of code:

    let validator = "http://127.0.0.1:26657";
    let client = HttpClient::new(validator).unwrap();
    let tx_hash = "D716F496764E6D9D24DDCB55841D6E5226261106BFAA4EE31DAC5258DE60B62A"
        .parse()
        .unwrap();
    let res = client.tx(tx_hash, false).await.unwrap();

2.1. If you prefer to use the same environment in which it failed for me, the following live validator can also be used:

    let validator = "https://testnet-milhon-validator1.nymtech.net";
    let client = HttpClient::new(validator).unwrap();
    let tx_hash = "84A0AD8A48D5CBCC0E551EF29FF96FF9D164699F6C5A53E3B7584A0FC6402E6D"
        .parse()
        .unwrap();
    let res = client.tx(tx_hash, false).await.unwrap();
  1. It's going to produce the error shown at the beginning of the issue description.

Note: I'm certain the block with the used hash exists as curl http://127.0.0.1:26657/tx\?hash\=0xD716F496764E6D9D24DDCB55841D6E5226261106BFAA4EE31DAC5258DE60B62A returns the relevant data. I'm including the response so that perhaps you might be able to spot invalid characters there or something:

{
  "jsonrpc": "2.0",
  "id": -1,
  "result": {
    "hash": "D716F496764E6D9D24DDCB55841D6E5226261106BFAA4EE31DAC5258DE60B62A",
    "height": "10802",
    "index": 0,
    "tx_result": {
      "code": 0,
      "data": "CgkKB2V4ZWN1dGU=",
      "log": "[{\"events\":[{\"type\":\"message\",\"attributes\":[{\"key\":\"action\",\"value\":\"execute\"},{\"key\":\"module\",\"value\":\"wasm\"},{\"key\":\"signer\",\"value\":\"punk1q9n5a3cgw3azegcddr82s0f5nxeel4pup8vxzt\"},{\"key\":\"contract_address\",\"value\":\"punk1uft3mmgha04vr23lx08fydpjym2003xuy9cnga\"}]},{\"type\":\"transfer\",\"attributes\":[{\"key\":\"recipient\",\"value\":\"punk1uft3mmgha04vr23lx08fydpjym2003xuy9cnga\"},{\"key\":\"sender\",\"value\":\"punk1q9n5a3cgw3azegcddr82s0f5nxeel4pup8vxzt\"},{\"key\":\"amount\",\"value\":\"100000000upunk\"}]},{\"type\":\"wasm\",\"attributes\":[{\"key\":\"contract_address\",\"value\":\"punk1uft3mmgha04vr23lx08fydpjym2003xuy9cnga\"},{\"key\":\"overwritten\",\"value\":\"true\"}]}]}]",
      "info": "",
      "gas_wanted": "200000",
      "gas_used": "136015",
      "events": [
        {
          "type": "transfer",
          "attributes": [
            {
              "key": "cmVjaXBpZW50",
              "value": "cHVuazE3eHBmdmFrbTJhbWc5NjJ5bHM2Zjg0ejNrZWxsOGM1bGg5Y2dkbQ==",
              "index": true
            },
            {
              "key": "c2VuZGVy",
              "value": "cHVuazFxOW41YTNjZ3czYXplZ2NkZHI4MnMwZjVueGVlbDRwdXA4dnh6dA==",
              "index": true
            },
            {
              "key": "YW1vdW50",
              "value": "NTAwMHVwdW5r",
              "index": true
            }
          ]
        },
        {
          "type": "message",
          "attributes": [
            {
              "key": "c2VuZGVy",
              "value": "cHVuazFxOW41YTNjZ3czYXplZ2NkZHI4MnMwZjVueGVlbDRwdXA4dnh6dA==",
              "index": true
            }
          ]
        },
        {
          "type": "message",
          "attributes": [
            {
              "key": "YWN0aW9u",
              "value": "ZXhlY3V0ZQ==",
              "index": true
            }
          ]
        },
        {
          "type": "transfer",
          "attributes": [
            {
              "key": "cmVjaXBpZW50",
              "value": "cHVuazF1ZnQzbW1naGEwNHZyMjNseDA4ZnlkcGp5bTIwMDN4dXk5Y25nYQ==",
              "index": true
            },
            {
              "key": "c2VuZGVy",
              "value": "cHVuazFxOW41YTNjZ3czYXplZ2NkZHI4MnMwZjVueGVlbDRwdXA4dnh6dA==",
              "index": true
            },
            {
              "key": "YW1vdW50",
              "value": "MTAwMDAwMDAwdXB1bms=",
              "index": true
            }
          ]
        },
        {
          "type": "wasm",
          "attributes": [
            {
              "key": "Y29udHJhY3RfYWRkcmVzcw==",
              "value": "cHVuazF1ZnQzbW1naGEwNHZyMjNseDA4ZnlkcGp5bTIwMDN4dXk5Y25nYQ==",
              "index": true
            },
            {
              "key": "b3ZlcndyaXR0ZW4=",
              "value": "dHJ1ZQ==",
              "index": true
            }
          ]
        },
        {
          "type": "message",
          "attributes": [
            {
              "key": "bW9kdWxl",
              "value": "d2FzbQ==",
              "index": true
            },
            {
              "key": "c2lnbmVy",
              "value": "cHVuazFxOW41YTNjZ3czYXplZ2NkZHI4MnMwZjVueGVlbDRwdXA4dnh6dA==",
              "index": true
            },
            {
              "key": "Y29udHJhY3RfYWRkcmVzcw==",
              "value": "cHVuazF1ZnQzbW1naGEwNHZyMjNseDA4ZnlkcGp5bTIwMDN4dXk5Y25nYQ==",
              "index": true
            }
          ]
        }
      ],
      "codespace": ""
    },
    "tx": "Cu8CCtACCikvY29zbXdhc20ud2FzbS52MWJldGExLk1zZ0V4ZWN1dGVDb250cmFjdBKiAgorcHVuazFxOW41YTNjZ3czYXplZ2NkZHI4MnMwZjVueGVlbDRwdXA4dnh6dBIrcHVuazF1ZnQzbW1naGEwNHZyMjNseDA4ZnlkcGp5bTIwMDN4dXk5Y25nYRqxAXsiYm9uZF9taXhub2RlIjp7Im1peF9ub2RlIjp7Imhvc3QiOiIxLjEuMS4xIiwibWl4X3BvcnQiOjE3ODksInZlcmxvY19wb3J0IjoxNzkwLCJodHRwX2FwaV9wb3J0Ijo4MDgwLCJzcGhpbnhfa2V5Ijoic3BoaW54a2V5IiwiaWRlbnRpdHlfa2V5IjoiaWRlbnRpdHlrZXkiLCJ2ZXJzaW9uIjoiMC4xMS4wIn19fSoSCgV1cHVuaxIJMTAwMDAwMDAwEhpCb25kaW5nIG1peG5vZGUgZnJvbSBydXN0IRJnClAKRgofL2Nvc21vcy5jcnlwdG8uc2VjcDI1NmsxLlB1YktleRIjCiED4ko1t6sfd4V/g52JVb3gtj+atBQuVsh7OKZNqJ+HqywSBAoCCAEYIRITCg0KBXVwdW5rEgQ1MDAwEMCaDBpAhVooZoxPyt4KE4lmu17RxqKl7azSTe4CWPLDLy6pRclDsVFCOHfzBoo9Hc2fBIyBBKXRi+T4s8AGZGBF8a8bVQ=="
  }
}

Also tx_search does work. For context, the code I've used for tx_search is as follows:

    let validator = "https://testnet-milhon-validator1.nymtech.net";
    let client = HttpClient::new(validator).unwrap();
	let query = Query::from(EventType::Tx).and_eq(
	    "tx.hash",
	    "D716F496764E6D9D24DDCB55841D6E5226261106BFAA4EE31DAC5258DE60B62A",
	);
	let res = client
	    .tx_search(query, false, 1, 20, Order::Ascending)
	    .await
	    .unwrap();
	println!("{:?}", res)
@jstuczyn jstuczyn added the bug Something isn't working label Aug 6, 2021
@tony-iqlusion
Copy link
Collaborator

Edit: sorry about my previous response, I was mistaken.

I managed to reproduce this with gaiad:

thread 'msg_send' panicked at 'called `Result::unwrap()` on an `Err` value: Invalid params: error converting json params to arguments: illegal base64 data at input byte 64 (code: -32602)

See cosmos/cosmos-rust#116

@thanethomson
Copy link
Contributor

Also managed to reproduce with Tendermint running the kvstore now. It looks like a difference between how the hash deserialization's handled through the simple HTTP GET interface and the JSON-RPC (POST) interface (we use the JSON-RPC interface from tendermint-rs).

I've tested a base64-encoded transaction hash and it works, but hexadecimal encoding doesn't. The Tendermint RPC docs for /tx seem to be only valid for the HTTP GET interface.

It seems like the HTTP URL client (like when you send GET requests using curl) has its own serialization approach. See here.

The POST interface, which expects JSON-RPC messages, is dynamically constructed using reflection in Go. See here. This autodetects the method argument types and applies the relevant deserialization strategy to it (which I assume for []byte is base64 en/decoding). There's brief mention of the fix for it over here: tendermint/tendermint#3330 (comment)

Will log an issue with the Tendermint team about this to ask about what to do here. Ideally we'd want the format to be consistent, but if we need to cater for base64 encoding here for now then so be it.

@thanethomson
Copy link
Contributor

tendermint/tendermint#6802 includes information on how to reproduce this locally without our API in the way.

@thanethomson thanethomson self-assigned this Aug 9, 2021
@thanethomson thanethomson added this to the Q3 2021 milestone Aug 9, 2021
@thanethomson
Copy link
Contributor

I'm going to implement the base64 encoding here instead of hexadecimal encoding. Will submit a PR soon!

@thanethomson
Copy link
Contributor

@jstuczyn, with regard to the /tx_search endpoint, from integration testing with a Tendermint node running the kvstore app, it looks to me like hexadecimal encoding does work. See here. This integration test passes in CI (i.e. it finds the transaction by its corresponding hash). The Hash::to_string() method converts to hexadecimal by default.

@jstuczyn
Copy link
Contributor Author

Yeah, as I said in my description /tx_search does work : )

@thanethomson
Copy link
Contributor

Yeah, as I said in my description /tx_search does work : )

Ah sorry! I missed that somehow 😁 Well, now we have an integration test that ensures the serialization format we use for an abci::transaction::Hash is supported by Tendermint 🙂

Once #948's merged, there are some other changes we need to implement in the next week or so and then we'll aim to cut a new release.

fmorency added a commit to fmorency/tendermint-rs that referenced this issue Oct 4, 2022
- Add base64 `tendermint::hash::Hash` encoding/decoding support
- Add base64 `Option<tendermint::hash::Hash>` encoding/decoding support
- Add missing `FromStr` import
- Rename `hash_base64` serializer to `tx_hash_base64`

Relates informalsystems#942
Links informalsystems#832
thanethomson added a commit that referenced this issue Oct 7, 2022
* Add block_by_hash RPC endpoint and tests

Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>

* rpc-probe part of this

Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>

* Fix comments

Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>

* Update .changelog/unreleased/features/832-block-by-hash.md

Co-authored-by: Thane Thomson <connect@thanethomson.com>
Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>

* cargo fmt

Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>

* cargo fmt

* Fix TM hash encoding

- Add base64 `tendermint::hash::Hash` encoding/decoding support
- Add base64 `Option<tendermint::hash::Hash>` encoding/decoding support
- Add missing `FromStr` import
- Rename `hash_base64` serializer to `tx_hash_base64`

Relates #942
Links #832

* Fix outgoing kvstore `block_by_hash` fixture

* Fix clippy

Signed-off-by: Felix C. Morency <1102868+fmorency@users.noreply.github.com>
Co-authored-by: Hans Larsen <hans@larsen.online>
Co-authored-by: Thane Thomson <connect@thanethomson.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working rpc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants