An attempt to query for a tx by hash or a set of tx(s) by event(s) via the legacy API yields the following error:
{
"error": "Unregistered interface types.isPublicKey_Sum"
}
master -- d4b0e5baa
This appears related to marshaling a public key with amino when that isn't supported. This will be address in #7276.
@anilCSE to double-check that this issue is solved once #7276 is merged.
Tested with #7276
{"error":"Unregistered interface tx.isModeInfo_Sum"}
on the legacy 1317 interface
{"error":"Unregistered interface tx.isModeInfo_Sum"}
Is this still an issue now that #7276 has been merged?
I'm seeing this bug again on stargate-5
http://34.66.55.131:1317/txs?transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z
I added (thorough) tests in #7992, however, I am still failing to reproduce the issue on simapp.
@zmanian Do you have by any chance the txHash of this tx? I'll query it via gRPC, see its content, reproduce the same tx on simapp, and try querying it again.
@clevinson I see you re-opened, did you manage to reproduce?
I couldn't reproduce this either.
This isn't happening for every tx. For instance this works.
http://34.66.55.131:1317/txs?transfer.recipient=cosmos13qhqwhzx74703avazhuf5hfxkwdx6wvsea4vgt
This also produces the error.
http://34.66.55.131:1317/txs?limit=100&page=1&tx.height=11101
This isn't happening for every tx.
Could you provide the details of a failing tx? A txHash should suffice.
There is evidence that is related to the existence of an IBC transaction in the response path.
For instance, http://34.66.55.131:1317/txs?transfer.recipient=cosmos1h2gacd88hkvlmz5g04md87r54kjf0klnwt25n9 has received an ibc transfer.
http://34.66.55.131:1317/txs?transfer.recipient=cosmos13qhqwhzx74703avazhuf5hfxkwdx6wvsea4vgt has not received an IBC transfer.
Printing a pretty error message on IBC txs has been solved in https://github.com/cosmos/cosmos-sdk/pull/7856, which I believe isn't included in rc3.
However, looking at that PR, i'm not 100% sure it handles all potential errors, so I added this: https://github.com/cosmos/cosmos-sdk/pull/7992#discussion_r527812040
What is the grpc query path to get transactions by tag?
How do you use the grpc endpoint with query parameters? http://34.66.55.131:1317/cosmos/tx/v1beta1/txs?transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z doesn't work
@faboweb Unfortunately we only added the /txs grpc-gateway endpoint in quite recently (#7842), and there hasn't been a release candidate tagged since. You should be able to verify that query paramters work when runing against a local node built off of master though.
Here's basic reference docs for using query parameters w/ grpc gateway
Also, looks like the URL is slightly different. It takes event query params with event key now, ex:
https://github.com/cosmos/cosmos-sdk/pull/7842/files#diff-61a9cb62b0e38da35032d7bc195c38b2c35c342c7302bf6dde5a483f63a96186R143
Any ETA on the next release version?
Can someone please post an example URL with the query params? Ideally @faboweb's initial query
The new endpoint for querying txs by event:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z&pagination.offset=0&pagination.limit=30
However, as Cory said, there's no live public node running SDK master.
This test on simapp might also help.
does the second = need to be URL escaped @amaurymartiny ?
@faboweb @aaronc I've just ran locally and verified that querying for single event attributes does work without URL encoding the value of event. However, I do think we should be encouraging developers to URL encode the event param value, as this is the only way to successfully query for multiple event attributes:
Example:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z&message.action=send&pagination.offset=0&pagination.limit=1
will not correctly search for both both transfer.recipient and message.action.
The correct request URL should look like:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.amount%3D100node0token%26message.action%3Dsend&pagination.offset=0&pagination.limit=1
@faboweb as for a next release version, we're currently coordinating with @zmanian to figure out the best timing for a next RC. Most likely sometime next week is my guess.
@faboweb @aaronc I've just ran locally and verified that querying for single event attributes does work without URL encoding the value of
event. However, I do think we should be encouraging developers to URL encode theeventparam value, as this is the only way to successfully query for multiple event attributes:Example:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z&message.action=send&pagination.offset=0&pagination.limit=1
will not correctly search for both bothtransfer.recipientandmessage.action.The correct request URL should look like:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.amount%3D100node0token%26message.action%3Dsend&pagination.offset=0&pagination.limit=1
@clevinson did you try with multiple event queryParam entries, something like below
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.recipient=cosmos1q9wtnlwdjrhwtcjmt2uq77jrgx7z3usrq2yz7z&event=message.action=send&pagination.offset=0&pagination.limit=1
@clevinson #8029 makes the event query params to be url escaped. The following request should work now:
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.amount%3D100node0token%26message.action%3Dsend
Addressed in #8039 . events is array now, following requests are valid
{base_url}/cosmos/tx/v1beta1/txs?event=transfer.amount%3D100node0token%26message.action%3Dsend/cosmos/tx/v1beta1/txs?events=message.action=send&events=message.module=bank")