Txs endpoint returns error on range operators

[nieejl]

Summary of Bug

Endpoint to query transactions, fails when defining height ranges on transactions (tx).
Path: /cosmos/tx/v1beta1/txs

Tendermint has support for range queries using the >= and <= operators. Supported formats are described here: https://docs.tendermint.com/v0.34/rpc/#/Websocket/subscribe
Until recently (v. 0.34.20 , possibly later), this worked for Celestia nodes as well, but seems to be broken in v.0.34.28. This seems to have changed after the update to mocha-3.

Adding a filter for <= 11140, is expected to return all transactions where the height is less than 11140, but instead returns an error.
https://api-mocha.pops.one/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height%3C=11140

Output:

{
  "code": 3,
  "message": "invalid event; event tx.height\u003c=11140 should be of the format: {eventType}.{eventAttribute}={value}",
  "details": [
  ]
}

I included a number of example queries below, to rule out some sources of error, and to showcase expected behavior:

Removing less than operator, returns the correct result:
https://api-mocha.pops.one/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height=11137

Node similar to pops node which fails on same query, to rule out any configuration issues:
https://api-t.celestia.nodestake.top/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height%3C=11140

Removing the range query, returns all transactions: https://api-mocha.pops.one/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27

Working example on a previous version (v 0.34.20): https://api.mocha.celestia.counterpoint.software/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height%3C=57700

Working example on cosmos node (using v.0.34.29) at time of writing:
https://cosmos-api.polkachu.com/cosmos/tx/v1beta1/txs?events=message.sender=%27cosmosvaloper1c4k24jzduc365kywrsvf5ujz4ya6mwympnc4en%27&events=tx.height%3E=15954604&events=tx.height%3C=15968451

Failure for multiple filters as well: https://api-t.celestia.nodestake.top/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height%3C=11140&events=tx.height%3E=11100

Version

0.34.28

Steps to Reproduce

Enter the below link in a browser:
https://api-mocha.pops.one/cosmos/tx/v1beta1/txs?events=message.sender=%27celestiavaloper1amm0umxqxxw8j2q60x78xs32s089606sdmvx92%27&events=tx.height%3C=11140

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[rootulp]

Thanks @nieejl for the extremely detailed issue. I'm still investigating but sharing notes that I'll continue to update:

• Working example on cosmos node (using v.0.34.29) at time of writing:

  I confirmed this node appears to be on CometBFT v0.34.29 per these lines and node_info which reports

      "version": "0.34.29",

• celestia-app v1.0.0-rc9 uses cometbft v0.34.28 per this line.

• The v0.34.29 changelog contains v0.37 pubsub/kvindexer: Handle big ints cometbft/cometbft#771 which may be related but the block heights you mentioned in the OP aren't big ints so I don't expect upgrading to v0.34.29 will resolve.

• I reproed the behavior on celestia-app v1.0.0-rc9, v0.13.3, v0.13.0

  celestia-appd start --home $CELESTIA_APP_HOME --api.enable

  $ curl http://localhost:1317/cosmos/tx/v1beta1/txs?events=tx.height%3C=10
  {
  "code": 3,
  "message": "invalid event; event tx.height\u003c=10 should be of the format: {eventType}.{eventAttribute}={value}",
  "details": [
  ]
  }%

• https://api.mocha.celestia.counterpoint.software/cosmos/base/tendermint/v1beta1/node_info claims to be on celestia-app v0.11.0

[Northa]

related to cosmos-sdk i believe.
Currently query is matched via regex on sdk 46+, and your query does not work because of the characters <>(gt,lt)
https://github.com/cosmos/cosmos-sdk/blob/v0.46.13/x/auth/tx/service.go#L48
must be smth like that i guess:
^[a-zA-Z_<>]+\.[a-zA-Z_<>]+=\S+$

[rootulp]

Great point! The working example here uses gaiad v10.0.2 which is on cosmos-sdk v0.45.16-ics.

Relevant PR cosmos/cosmos-sdk#12474 and backport cosmos/cosmos-sdk#13598 which appears to be first released in cosmos-sdk v0.46.4.