To achieve this behaviour, users have to add a match.event keyword to their query. Otherwise, the index search system falls back to the original behaviour.

To clarify, if match.events=1 is present in a query sent to an old tendermint version, the query will not behave like before. The implication for hermes is that it needs to format the query based on the version of the chain the query is sent to. We are trying to avoid this and wondering if there is a backwards compatible solution.

On current version (without your changes) this returns two blocks:

http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query="send_packet.packet_sequence='890' AND send_packet.packet_src_channel='channel-2'"

While this finds 0 blocks:

http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query="send_packet.packet_sequence='890' AND send_packet.packet_src_channel='channel-2' AND match.events = 1"

cc @romac who brought this up: Is it possible to change the RPC to add an extra argument or option, something like:
http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query=_&page=_&per_page=_&order_by=_&match_events
(with default false if new flag not present).

This currently works on old version and returns the two blocks:

http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query="send_packet.packet_sequence='890' AND send_packet.packet_src_channel='channel-2'"&match_events=true"

Can we make it work within your PR branch? Or is this something that's already handled here? If it is, can you write one unit test for it?

To clarify, if match.events=1 is present in a query sent to an old tendermint version, the query will not behave like before.

You are issuing the match.events=1 to and old tendermint version that does not support this? That is probably why the result has 0 blocks. What I did preserve is that the new Tendermint version will be able to process data that was indexed with an old version but it will obviously not be able to differentiate between different events in that case. That is, the event identifier field will be set to the same value for any entry in the kvstore that was indexed w/o it. But essentially you want to avoid older versions not returning anything when seeing the keyword. The only way I currently see to avoid this is making this behvaiour (with match.events=1 currently) default and having users explicitly use match.events=0 if they want the old behaviour. This would not change the behaviour for old versions but users of a new version would have to be aware of this.

This currently works on old version and returns the two blocks:

http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query="send_packet.packet_sequence='890' AND send_packet.packet_src_channel='channel-2'"&match_events=true"

match_events should be with a . instead of _ unless you internally parse it. On old versions however, this flag is basically ignored as it will always return two blocks - there is no way to know to which even an attribute belongs.

I am currently running local tests using two TM versions to evaluate the behaviour of the indexer when upgrading from an old to a new version.

@ancazamfir an additional question, can you tell me whether you expect the same behaviour from the transaction indexer or is the block indexer your main concern?

http://provider-sentry-01.goc.earthball.xyz:27001/block_search?query="send_packet.packet_sequence='890' AND send_packet.packet_src_channel='channel-2'"&match_events=true

there was an extra "..i removed

match_events should be with a . instead of _ unless you internally parse it. On old versions however, this flag is basically ignored as it will always return two blocks - there is no way to know to which even an attribute belongs.

this is proposing a new flag, outside the query string. This would be a better solution for hermes as would work in a backwards compatible way.

, can you tell me whether you expect the same behaviour from the transaction indexer or is the block indexer your main concern?

ah, I thought the problem is not present in the tx_indexer. I need to test this. will get back to you.

@ancazamfir it is present and this PR has a solution for it too, but making it backwards compatible seems to be a bigger feat then I'd expected.