Replies: 3 comments 8 replies
- 10000
-
|
Hi @napelvs, The Go relayer tracks this information, which you can find more about here: cosmos/relayer#1235. We plan to track this in Hermes eventually. However, I haven't had the time to investigate this in more detail, so I don't have more information on how this can be achieved at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ljoss17! Thanks for your answer 🙏 From my understanding, I would have to run the go relayer software myself, expose the Prometheus port, then make it available for me to query. Not to mention each path would need to be manually added into the config of the relayer. Is my understanding correct? If so, then it's not suitable for my usage. |
Beta Was this translation helpful? Give feedback.
-
|
That would be one possibility. |
Beta Was this translation helpful? Give feedback.
-
|
@napelvs You can also retrieve the list of consensus states for a given client, and look at the timestamp of the latest one which corresponds to the time at which it was last updated. To this end, you can issue this gRPC query to the node (either in code, or using |
Beta Was this translation helpful? Give feedback.
-
|
Glad to hear! And sorry for not providing more guidance right off the bat, next time please feel free to ask for clarifications, we're always happy to help :) |
Beta Was this translation helpful? Give feedback.
-
|
Hey @romac, I'm back with some more questions. On the Osmosis client ID, the following query returns the most recent object first - where I can get the most recent timestamp (exactly what I'm looking for).
On the other hand, when utilizing the exact same query as above, but changing the client ID to ``07-tendermint-91` (Kava), it doesn't do what I expect - it doesn't return the latest object with the latest timestamp.
I see there are more recent objects in there, but I need to set a limit of THOUSANDS to get to the most recent timestamp, which isn't feasible as it takes a long time and it's inefficient. It's odd the same query returns different results based on the client ID. What's the issue here, and how can I make sure I get consistent results? |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure exactly what the issue is, but I suspect it's a limitation of the CometBFT indexer (maybe @sergio-mena or @jmalicevic knows more). As a workaround, you might want to try the following:
Let me know if that helps! |
Beta Was this translation helpful? Give feedback.
-
|
@romac Thanks for this. I've started to work on it, but I've ran into a doubt. You've said I need a very large limit for the first query (ConsensusStateHeights) and you given an example of 2^32-1 which results in 4294967295. How did you get to this number, and isn't it way too big? Or it doesn't really matter since there's only so many "ConsensusStateHeights" objects the query will return anyway? Or maybe I misunderstood the calculation there. |
Beta Was this translation helpful? Give feedback.
-
It's mostly arbitrary, but 2^32-1 is the maximum value that can be held in a 32-bit unsigned integer. In CometBFT, heights are expressed as 64-bits unsigned integers so we could also have picked 2^64-1, but the former is plenty enough for retrieving all consensus state heights.
Exactly. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this issue is more related to the operation of the relayers than to Comet's operation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone.
I'm developing an app where I need to know the time left for an IBC client to expire. Given my research, I've found the only possible way to get this piece of information is to retrieve:
The first is easily accessible, but I'm having issues retrieving the second one.
This is what I have right now:
[osmosis_rest_api_url]/cosmos/tx/v1beta1/txs?order_by=2&events=send_packet.packet_src_channel='channel-0'&events=send_packet.packet_src_port='transfer'&events=send_packet.packet_dst_channel='channel-141'&message.action='/ibc.core.client.v1.MsgUpdateClient'&limit=1The issue I run into is that the
message.action='/ibc.core.client.v1.MsgUpdateClient'parameter in the query doesn't work. Also, I see that thechain_idvalue in the json response doesn't align with the channels mentioned in the query. It should be either Osmosis or Cosmos, but I get random chains I'm not interested in.While help in achieving this query to respond the way I expect is greatly appreciated, further information into how to filter information would be paramount in making sure I don't need to ask around every time. I want to be as self-sufficient as possible. Send in any helpful documentation and tips on anything related to REST API calls and filtering the JSON responses.
Thank you for reading.
Beta Was this translation helpful? Give feedback.
All reactions