Description
Hello!
I noticed a change during a migration from v0.34 to v1.0 that is related to commit Propagate CheckTx errors to caller.
From what I understood, the caller always received a HTTP 200 status as response to broadcast-tx-commit, but now, if check-tx fails it returns a HTTP 500 status.
We adapted our code accordingly but we noticed that the format of the error code also changed. Before, we were receiving the response:
{
"jsonrpc": "2.0",
"id": -1,
"result": {
"check_tx": {
"code": 1,
"data": "OmZvbw==",
"log": "",
"info": "{:foo \"bar\"}",
"gas_wanted": "0",
"gas_used": "0",
"events": [],
"codespace": "foo.abci",
"sender": "",
"priority": "0",
"mempoolError": ""
},
"deliver_tx": {
"code": 0,
"data": null,
"log": "",
"info": "",
"gas_wanted": "0",
"gas_used": "0",
"events": [],
"codespace": ""
},
"hash": "7D973965A9D33367FD75257110B56C59B89C4A9AE28F0EC9C16B16DCEC36A0C8",
"height": "0"
}
}But now we are receiving the response:
{
"jsonrpc": "2.0",
"id": -1,
"error": {
"code": -32603,
"message": "Internal error",
"data": "broadcast error on transaction validation: tx 8750356F66189FE708B06E3F2D5A6EBA021DDC1E73E4AD23E50B3D326B35BBF6 is invalid: code=1, data=3A666F6F, log='', codespace='foo.abci'"
}
}Our main concern is that the fields code, data, info and codespace were encoded as JSON before and now they are plain strings in the data field, what I'd say is less reliable.
This change of interface was intended by design? The best approach to extract this data from the caller is to parse the string in data?