Block NFT Transfers response fields

Hi there, can you please explain for request “get /block/{block_number_or_hash}/nft/transfers” there is in response 2 fields: 1) index_complete 2) block_exists.
If make a request right after block has appeared( by listening logs ) then initially there is no data and both block_exists and index_complete are false. If make a request in a couple of seconds then there appears data, but index_complete and block_exists may still be false, and only later on( 4-10 seconds aprox ) index_complete becomes true, and then even more later block_exists becomes true. Thats at least usual behaviour that i saw, but in some examples things act slightly different, and block_exists may becomes true at the same time as index_complete.
Can you please explain meaning of “index_complete” and “block_exists” fields. And when is it safe to say that data in “result” attribute is all NFT data for the given block and there wont be any changes in it ?

1 Like

index_complete will be true when all the transactions that are on that block are synced. If you compare the object data between index_complete: false and index_complete: true you might see the difference between the total transactions.

I think block_exists will be true when the block is successfully added on blockchain. So block_exists should be true before even index_complete is true.

One thing I observed is that the index_complete is returning true for the blocks that did not exist or has zero transactions.
For example if you check data for block 20000000 (which does not exist) on eth, I am receiving index_complete: true and block_exists: false.

Can you verify if this is true in your case?

1 Like

After checking live blocks, it appears that in the majority of scenarios it is true: block_exists is set to true usually first, and then index_complete becomes true, or they become true at the same time. But ive also saw examples where index_complete is true, but block_exists is false. Its a bit hard to provide examples that may be replicated, because i assume by the moment of reading block will be set to true already, even though example recently checked block 14518490 and there index_complete was true, and block_exists is false. And also ive figure out that for some blocks total_count may be updated after both index_complete and block_exists was set to true: block numbers: 14517576, 14518338, 14517649, but if recheck them currently - everything is already updated

One more weird thing that found - is a stuck block number 14496126 - from 31st of March which is showing index_complete: false and block_exists: true. But so far was able to catch not so many blocks with similar behaviour. I assume that nothing will change with that block already, but still a bit curious what may be the best strategy of pulling data based on block number and make sure that all data are squeezed of it successfully?

what is the chain for that block number? (found it, eth)

maybe we need to fix it / reindex it

Do you mean like a second-level verification?
Maybe you could try to compare the data with getBlock function data. It should give all the transitions from a block including the data from getnfttransfersbyblock function.

Ahh yeah sorry missed that - talking about main net ETH

By the way found issue that can replicate at least right now. Block number 14538729 - doesnt have transaction 0x70be732fb4009f12e8e108ec2b367224c829c7544756540a7f97da90e9e23fb3 in it( for api request /block/14538729/nft/transfers?chain=eth ) But this transaction looks valid nft minting transaction. And for this block output is block_exists: true, index_complete: true, total: 65 currently.

Ah thanks @johnversus! Yeah that maybe a right way of doing things, just want to avoid parsing all block transactions and was curious if there is a way to make it so with less requests