[RPC] incorrect logIndex in logs received from eth_getfilterchanges

[debris]

logIndex: QUANTITY - integer of the log index position in the block. null when its pending log.

Currently it's always 0.

Steps to reproduce:

• create multiple transactions. Make each one create an event.
• mine them in the same block
• event when transactionIndex is > 0, logIndex is 0

{
  "address": "0xfe69e6f32a2a02b3169b072a7631ff33bf472ed0",
  "blockNumber": 115,
  "logIndex": 0,
  "blockHash": "0x7dcaec77bdc5bd3dc1c96cdc3504ed23dc6132ea756ab3cb56a2ddaccae432d5",
  "transactionHash": "0x09abbb095230e93b725929a8671a6c7e8ba51d7b8f3e4ae54db1ca7135ede61d",
  "transactionIndex": 4,
  "event": "Incremented",
  "args": {
    "odd": true,
    "x": "91"
  }
}

[frozeman]

Thanks for that find 👍

[tgerring]

@obscuren I don't see the Index modified anywhere in core/state/log.go or core/filters.go. Is there somewhere else events might be processed where this is set? If not, I suspect this is simply not being tracked and defaults to 0 as a uint.

[obscuren]

This might have been accidentally removed when the log messages were re-written. It should be done prior to storing the receipts to the database in the BlockProcessor.processWithParent

[tgerring]

@debris Can you provide some example RPC calls to create the logs?

[tgerring]

Using geth javascript console

primary = registrar.addr('tg')
contract = eth.compile.solidity("contract FireLog{event Deposit(address from, uint value); function() { if (msg.value > 0) Deposit(msg.sender, msg.value);}}").FireLog
// 0xba3fd30d9765a943d4f6a6ec513c84193ebfa598
twocontract = eth.compile.solidity("contract TwoLogs{ event Deposit(address from, uint value); event BigSpender(uint value); function() {Deposit(msg.sender, msg.value); if (msg.value > 100) BigSpender(msg.value);}}").TwoLogs
// 0x5de875d850afc78180b6f6cb054089c2461cee8d
onecontractaddress = eth.sendTransaction({from:primary,data:contract.code,gas:1000000,gasPrice:web3.toWei(10, "szabo")})
twocontractaddress = eth.sendTransaction({from:primary,data:twocontract.code,gas:1000000,gasPrice:web3.toWei(10, "szabo")})

Getting multiple log fires into a single block:

eth.sendTransaction({from:primary,to:onecontractaddress,value:99,gasPrice:web3.toWei(10, "szabo")})
eth.sendTransaction({from:primary,to:onecontractaddress,value:100,gasPrice:web3.toWei(10, "szabo")})
eth.sendTransaction({from:primary,to:twocontractaddress,value:101,gasPrice:web3.toWei(10, "szabo")})
eth.sendTransaction({from:primary,to:twocontractaddress,value:102,gasPrice:web3.toWei(10, "szabo")})

I see this output (a log i patched in):

I0617 00:20:34.546293   30963 block_processor.go:262] *** block 618750 log index 0 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000063 be11127e2cd3ad6c8da43a485840833ae05084d09bcfb01c8ed79266823b0d57 0 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0
I0617 00:20:34.546364   30963 block_processor.go:262] *** block 618750 log index 1 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 de1da715d524316858657551dc94f538ee1d520d176091ae048cf0d2175cb404 1 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0
I0617 00:20:34.546492   30963 block_processor.go:262] *** block 618750 log index 2 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 821aa58a109091becd53c184e7ffb968b12dbc88868f39261b7652ab0e192a9c 2 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0
I0617 00:20:34.546541   30963 block_processor.go:262] *** block 618750 log index 3 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97]                                                                 0000000000000000000000000000000000000000000000000000000000000065 821aa58a109091becd53c184e7ffb968b12dbc88868f39261b7652ab0e192a9c 2 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0
I0617 00:20:34.546688   30963 block_processor.go:262] *** block 618750 log index 4 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000066 97542d79e8b0ba8025613873fc97183208dedc431960d4d53446ec79140f1189 3 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0
I0617 00:20:34.546734   30963 block_processor.go:262] *** block 618750 log index 5 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97]                                                                 0000000000000000000000000000000000000000000000000000000000000066 97542d79e8b0ba8025613873fc97183208dedc431960d4d53446ec79140f1189 3 7b305e97d4391ebfa84b24618f989a0e7def06d4a0f940930e47298c7d4883d3 0

Would you expect logIndex to increment as "log index" indicates? If not, what behaviour would you expect?

[tgerring]

@obscuren I finally triggered some outputs where Index (last column) is set to something besides 0, but it doesn't make much sense at first glance:

I0617 00:34:33.831516   30963 block_processor.go:262] *** block 618831 log index 0 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 27c35546a108981016658a3b298ab96e30c8e294101efc02a906389b20e86c0e 1 5d41c3683748c3eb2a5826a05f4e7f6009c7dbddd8e750bdcf367bc7eba0caf4 0
I0617 00:34:33.831564   30963 block_processor.go:262] *** block 618831 log index 1 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 16219e89ccaeb8dd22a2718f8d057c2958d68dbb5ea26ea6135bd27c706eca59 2 5d41c3683748c3eb2a5826a05f4e7f6009c7dbddd8e750bdcf367bc7eba0caf4 0
I0617 00:34:33.831624   30963 block_processor.go:262] *** block 618831 log index 2 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 b284606329f3017bf71b703a69b8a98ec3400a8d73b7c12ae05d5ca59df57130 3 5d41c3683748c3eb2a5826a05f4e7f6009c7dbddd8e750bdcf367bc7eba0caf4 0
I0617 00:34:33.831684   30963 block_processor.go:262] *** block 618831 log index 3 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97]                                                                 0000000000000000000000000000000000000000000000000000000000000065 b284606329f3017bf71b703a69b8a98ec3400a8d73b7c12ae05d5ca59df57130 3 5d41c3683748c3eb2a5826a05f4e7f6009c7dbddd8e750bdcf367bc7eba0caf4 2
I0617 00:34:33.831854   30963 block_processor.go:262] *** block 618831 log index 4 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 01725729ff9f34f3fe7cabfbcd189efecc8479d7ea77d4f7ab1e9e221a1c9d98 0 5d41c3683748c3eb2a5826a05f4e7f6009c7dbddd8e750bdcf367bc7eba0caf4 0

Another spot:

I0617 00:31:29.822500   30963 block_processor.go:262] *** block 618814 log index 0 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 a88fb770736a83504544a3bcba6c31fd9a3ecd4eb59f7671e78ae804e4ee2fd8 3 6c02dc235fb287b31091a29e82309171072ff228a6e3be516329d8f36cd808ee 0
I0617 00:31:29.822550   30963 block_processor.go:262] *** block 618814 log index 1 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97] 0000000000000000000000000000000000000000000000000000000000000065 a88fb770736a83504544a3bcba6c31fd9a3ecd4eb59f7671e78ae804e4ee2fd8 3 6c02dc235fb287b31091a29e82309171072ff228a6e3be516329d8f36cd808ee 0
I0617 00:31:29.822668   30963 block_processor.go:262] *** block 618814 log index 2 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 ed740c6a3cf12eb81acae0c35152d7f89275e41f6ca2e9e9e6b19bb84de01226 0 6c02dc235fb287b31091a29e82309171072ff228a6e3be516329d8f36cd808ee 0
I0617 00:31:29.822717   30963 block_processor.go:262] *** block 618814 log index 3 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 4121784ebc2046bcbfc93b552f76b46077e077860c37f9af3427c811a4d1f6bb 1 6c02dc235fb287b31091a29e82309171072ff228a6e3be516329d8f36cd808ee 0
I0617 00:31:29.822919   30963 block_processor.go:262] *** block 618814 log index 4 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 35c784d9d754f2b1762f59b0d7934e5acdd8b529ce823b2040e549a0b5380b1a 2 6c02dc235fb287b31091a29e82309171072ff228a6e3be516329d8f36cd808ee 2

And another:

I0617 00:20:42.906929   30963 block_processor.go:262] *** block 618750 log index 0 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000065 821aa58a109091becd53c184e7ffb968b12dbc88868f39261b7652ab0e192a9c 2 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 0
I0617 00:20:42.907013   30963 block_processor.go:262] *** block 618750 log index 1 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97] 0000000000000000000000000000000000000000000000000000000000000065 821aa58a109091becd53c184e7ffb968b12dbc88868f39261b7652ab0e192a9c 2 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 0
I0617 00:20:42.907056   30963 block_processor.go:262] *** block 618750 log index 2 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000066 97542d79e8b0ba8025613873fc97183208dedc431960d4d53446ec79140f1189 3 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 0
I0617 00:20:42.907096   30963 block_processor.go:262] *** block 618750 log index 3 is log: 5de875d850afc78180b6f6cb054089c2461cee8d [47b5e9112506fe3dc7ed145ccd176e797e7738cc4657fc3aa8a6091342c38a97] 0000000000000000000000000000000000000000000000000000000000000066 97542d79e8b0ba8025613873fc97183208dedc431960d4d53446ec79140f1189 3 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 0
I0617 00:20:42.918422   30963 block_processor.go:262] *** block 618750 log index 4 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000063 be11127e2cd3ad6c8da43a485840833ae05084d09bcfb01c8ed79266823b0d57 0 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 0
I0617 00:20:42.918464   30963 block_processor.go:262] *** block 618750 log index 5 is log: ba3fd30d9765a943d4f6a6ec513c84193ebfa598 [e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c] 000000000000000000000000d1ade25ccd3d550a7eb532ac759cac7be09c27190000000000000000000000000000000000000000000000000000000000000064 de1da715d524316858657551dc94f538ee1d520d176091ae048cf0d2175cb404 1 da88b33c002015cedd34a3a475888ae0def98f15a2c571014ac6fd74367a387c 1

[tgerring]

@debris @frozeman Can you describe how the ordering should be? Is it simply 0...N for all logs in that block sorted first by transaction index? i.e, if transaction 0 contains 2 logs and transaction 1 contains 1 log and transaction 3 contains 1 log, then the logs would be ordered as such:

logindex txindex
0 0
1 1
2 1
3 2

[frozeman]

@obscuren could you have a look, as i don't know even what the log index is anyway.
but i guess the log index is for each transaction. e.g. if you have two transactions and both have only one log, then the log index for both would be 0.

if one transactions generated two logs, then the index would be 0 and 1.

So its basically the index of the logs in a transaction receipt (which can only belong to one transaction)

This number would only make really sense when we have eth_getReceipt implemented. See: #1042, which returns you an array of logs generated by that transaction.

[tgerring]

@frozeman if neither you nor @debris know what this is used for, I would nominate to remove it. As a simple counter 0...N of the collection it's pretty useless. However, if it is used to indicate the order of the logs being created within each transaction, then we can be explicit about ordering without relying on the collection being properly sorted.

cc: @wanderer

[frozeman]

I don't fully agree. If the log index specifies the index position in the receipt log array, then this information helps to identify and match logs within a transaction receipt.

As well as helps to understand at which order logs were caused by a transaction.

[debris]

0 0
1 1
2 1
3 2

This is the correct ordering according to the current version of wiki.

As far as I know logIndex was introduced to distinguish two logs (which might be the same) created within same transaction. So ordering logs within transaction is also sufficient. For me it doesn't matter what ordering we will choose as long as it will be properly described in wiki.