Block lose transactions?

[yangkun0824]

I use eth_newBlockFilter to get new blocks. it will get full transactions. the transaction count may smaller than which the block really has.

the following log means: blockNumber#(transaction count which eth_newBlockFilter get)#(transaction count using eth_getBlockTransactionCountByHash)

losing 10 transactons.
01/08_23:47:27 Check:11614988#163#163

rescan after 8 hours.
01/09_07:43:25 Check:11614988#173#173

Any suggestions?

[rjl493456442]

I don't understand, these two numbers are equal right?

# transaction count which eth_newBlockFilter get
and
# transaction count using eth_getBlockTransactionCountByHash

[yangkun0824]

I don't understand, these two numbers are equal right?

# transaction count which eth_newBlockFilter get
and
# transaction count using eth_getBlockTransactionCountByHash

the transaction count are equal. but the number which the first time get is wrong, losing 10 transactions.

[rjl493456442]

The chain reorg usually can happen. The block #11614988 might be different(different hash) actually.

[yangkun0824]

reorg

what should I do if i meet this problem? when i scan the blocks, my transaction sometimes unfortunately in the set of losing transactions

[yangkun0824]

The chain reorg usually can happen. The block #11614988 might be different(different hash) actually.

好吧，你是浙大的，校友好

[yangkun0824]

The chain reorg usually can happen. The block #11614988 might be different(different hash) actually.

what does the reorg do? the block content will change?

[rjl493456442]

The reorg means this specific block(e.g. #100 with hash 0xabc) is included, but 1 minute later the #100 is replaced by another block 0xdef because this chain has a higher total difficulty.

what should I do if i meet this problem?

Usually, a safe approach is to set a minimal confirmation threshold(e.g. 30 blocks). The possibility that the block is reorg after that many additional confirmations is super low.
In your specific use case, you can filter out the filter changes without enough confirmation.

[yangkun0824]

The reorg means this specific block(e.g. #100 with hash 0xabc) is included, but 1 minute later the #100 is replaced by another block 0xdef because this chain has a higher total difficulty.

what should I do if i meet this problem?

Usually, a safe approach is to set a minimal confirmation threshold(e.g. 30 blocks). The possibility that the block is reorg after that many additional confirmations is super low.
In your specific use case, you can filter out the filter changes without enough confirmation.

i see, really thanks.

[rjl493456442]

Will close it now.
Feel free to open a new issue if you still have some questions/problems or to reopen this one.