comet RPC for `/tx` doesn't seem to be working

[tzemanovic]

This requires Comet config to have tx indexer enabled (e.g. set to "kv"), but even with that it doesn't seem to work. We need to figure out why and add a test coverage for it

[yito88]

Note: Indexing was disabled #1278 because the disk space was occupied by the index.

[brentstone]

Ah! So can a node still simply re-enable indexing with the --tx-index arg to namadan ledger run in addition to the kv arg in the config?

[yito88]

The option --tx-index has been removed in 4ccb9cfed85a4408006bf5054502182944041f05

[tzemanovic]

Yup, the indexer is now controlled directly via comet section of the config. By default it's disabled and then the /tx endpoint returns an error message saying it has to be enabled. When you enable it and then submit another tx, it returns an error that it's not able to find it

[tzemanovic]

The issue is that our tx hash no longer matches CometBFT tx hash

[tzemanovic]

The /tx endpoint doesn't contain any useful information even when you use the CometBFT tx hash to find it (besides block height), because this information is being filled in with default in our ABCI++ shim layer. That means that this cannot be improved until we upgrade CometBFT (#4156) at which point it would be beneficial to ensure that Namada tx hash matches CometBFT hash and to return txs' events in the FinalizeBlock response. Additionally, we should attach the inner tx hash attribute to the events (at protocol level) to disambiguate tx association in batched txs.

To query tx and its events in the meantime one can either:

1. Use namadac tx-result to find the tx result (or namada_sdk::rpc::query_tx_status in code). These events are stored in Namada state and are not persisted on e.g. node restart. This also only finds the tx/applied events, but not other events that may be emitted by a tx
2. Use CometBFT /block_results?height={tx_applied_height} to find all the events emitted in this block. The events emitted by the tx in question can be found in the end_block_events field, following the tx application order. The relevant event has "type": "tx/applied" and { "key": "hash", "value": "{tx_hash}"} with the matching tx_hash. IF there are other relevant events they will be directly preceding this event, following any previous "tx/applied" event (if any)