Receipts contain incorrect log indices

[DrZoltanFazekas]

For instance the proto-testnet block 0x9b08fd0e1278a9a15fcc645fed8ff5c6cdc9cf9440095b38bd92a97ee0bb4735 imported from ZQ1 contains 2 transactions. The first transaction has 2 logs i.e. their log indices are 0x0 and 0x1 so the second transaction's log index must be 0x2 which is the case on ZQ1

cast receipt 0x02a2c597dc4039d6bc0dcd63cd85b496da891c74125281393b488f2354d00c8a --json --rpc-url https://dev-api.zilliqa.com | jq '.logs.[].logIndex'

"0x2"

but not on ZQ2 where it is 0x0

cast receipt 0x02a2c597dc4039d6bc0dcd63cd85b496da891c74125281393b488f2354d00c8a --json --rpc-url https://api.zq2-prototestnet.zilliqa.com | jq '.logs.[].logIndex'

"0x0"

It might be an API issue or a persistence conversion issue

[maxconway]

So looking at the code for the eth APIs, the log_indicies are created as the functions return, and are just an index inside that specific function's returned data, rather than overall.

So e.g. transaction 1 might have 3 logs, with indicies 0,1,2. Transaction 321 might have 4 logs, and their indicies would be 3,2,1,0.

And that's all generated in the function return, rather than being something in the database.

So how did this work on ZQ1? Did each log have its own index? If we want to replicate that behaviour we'd have to add this as a new DB field.

[maxconway]

Plan is to have log indices as the index into the log within the block, and to calculate them on the fly