Missing transactions in block 6754141

[ryujimin220]

Problem (I am resubmitting this issue since it got closed before getting solved)

I'm trying to query (from cosmos archive node) transactions in block 6754141 but it seems like there's an issue.

Problem details

Block 6754141 shows two transactions using the “blockchain” call which is also confirmed by mintscan (https://www.mintscan.io/cosmos/blocks/6754141). However, when I make the tx_search call, it's returning 0 transactions.

The same issue has occurred not only on the archive node I'm using but also on other Node providers' archive nodes.

I tried the same on block 6754140 (one block before the targeted block) and on block 6754142 (one block after the targeted block) and both worked fine (I was able to get list of transactions when I make the tx_search call.

Any idea what the problem is? Is the a bug? Anyone else facing or have faced similar issue?

Again, I AM using ARCHIVE Node, pruning is set to nothing

Thanks in advance!

Please also refer to the issue below:

#2694

[mmulji-ic]

Thanks @ryujimin220 for reporting, I'll check with the Comet team why this has occurred, they're supporting the db and p2p layers.

[andynog]

Hi @ryujimin220, I'm Andy from the CometBFT team. Could you please let us know how you're using the tx_search querying to find that transaction. This will be helpful for @mmulji-ic and I troubleshoot this issue. Thanks !

[ryujimin220]

Hi @andynog @mmulji-ic , thanks for your responses!

blockchain call --> shows 2 txs

curl localhost:26657 --header "Content-Type: application/json" --request GET --data '{"jsonrpc":"2.0", "id":0, "method":"blockchain", "params":["6754141","6754141"]}'
{"jsonrpc":"2.0","id":0,"result":{"last_height":"18769243","block_metas":[{"block_id":{"hash":"A43D7646212CD7781568BA2D8F3FEB045EF312898BB322356989DE5A36DB789C","parts":{"total":1,"hash":"251525748D218AB4F0E4E969DF7EC8230FA64DCB0778CAE5B5A2E5476915810A"}},"block_size":"14438","header":{"version":{"block":"11"},"chain_id":"cosmoshub-4","height":"6754141","time":"2021-06-29T10:09:52.790318277Z","last_block_id":{"hash":"01C7EA94231B932E399BEB9D7E8242AF25A3A614B996569635B35007825BBDAE","parts":{"total":1,"hash":"BE0EA43A2ED93A2952ED35951A1D81367088817885E335DB3F13C6475DEF73F4"}},"last_commit_hash":"42803B7727ED43B1F17F1223EB4A7AE75F6980C0C487CDD15A58F1951CC84B5B","data_hash":"2226775513103302CB081C6BD2E52C7B4CFC2B050DBD36F35A0315FE71A44755","validators_hash":"F80B2048D40E062DAD3CF770D91067E0E5206C6CFCB9A41BBE79C121870662FE","next_validators_hash":"F80B2048D40E062DAD3CF770D91067E0E5206C6CFCB9A41BBE79C121870662FE","consensus_hash":"0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8","app_hash":"DEAE8FAAF1B604DD94477E3979A4BC7760B0C7A567C602542013E656F91FB724","last_results_hash":"63BE60C199831621F0E72DEAAC28B2E6A70B731322258A071AA13874454717A2","evidence_hash":"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855","proposer_address":"818964B4FB36D28109C3E853778B33231B27C5FC"},"num_txs":"2"}]}}

tx_search call --> shows 0 txs

curl localhost:26657 \
> --header "Content-Type: application/json" \
> --request GET \
> --data '{"jsonrpc":"2.0", "id":0, "method":"tx_search", "params":["tx.height=6754141" , true, "1", "100", "asc",true]}'
{"jsonrpc":"2.0","id":0,"result":{"txs":[],"total_count":"0"}}

And as you can see from the block explorer, it's confirmed that it has 2 transactions.
https://www.mintscan.io/cosmos/block/6754141

Again, I'm running ARCHIVE node that has pruning turned OFF.
Just don't understand why tx_search call returns 0 tx while blockchain call returns 2 txs for the same block height 6754141

Could this possibly be a bug?? hmm..

Thanks in advance!!!

[andynog]

Thanks @ryujimin220 , in your app.config (in $HOME/.gaiad/config) what is the value for index-events?

# IndexEvents defines the set of events in the form {eventType}.{attributeKey},
# which informs Tendermint what to index. If empty, all events will be indexed.
#
# Example:
# ["message.sender", "message.recipient"]
index-events = []

and in the config.toml the value of indexer ?

#######################################################
###   Transaction Indexer Configuration Options     ###
#######################################################
[tx_index]

# What indexer to use for transactions
#
# The application will set which txs to index. In some cases a node operator will be able
# to decide which txs to index based on configuration set in the application.
#
# Options:
#   1) "null"
#   2) "kv" (default) - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
#               - When "kv" is chosen "tx.height" and "tx.hash" will always be indexed.
indexer = "kv"

[ryujimin220]

Hi @andynog
app.toml

# IndexEvents defines the set of events in the form {eventType}.{attributeKey},
# which informs Tendermint what to index. If empty, all events will be indexed.
#
# Example:
# ["message.sender", "message.recipient"]
index-events = []

config.toml

[tx_index]

# What indexer to use for transactions
#
# The application will set which txs to index. In some cases a node operator will be able
# to decide which txs to index based on configuration set in the application.
#
# Options:
#   1) "null"
#   2) "kv" (default) - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
#               - When "kv" is chosen "tx.height" and "tx.hash" will always be indexed.
#   3) "psql" - the indexer services backed by PostgreSQL.
# When "kv" or "psql" is chosen "tx.height" and "tx.hash" will always be indexed.
indexer = "kv"

Here it is.
Seems like it's just like the ones you provided above?

[mmulji-ic]

Hi @andynog any update on this one?

[MSalopek]

@ryujimin220 Where did you donwload the archive and which gaiad binary version are you using?

It could be the Tx is not indexed so the search does not work as expected - sometimes it can happen. Not all nodes have all the Txs indexed.

[MSalopek]

Related to: #2889

Let's keep the discussion there.

Most likely the node being used has pruned the Txs or they were somehow removed from state.

We do not control publicly available archive nodes and some of them may not have all Txs.

Closing as duplicate of #2889.