[RPC] incorrect logIndex in logs received from eth_getfilterchanges #1226

debris · 2015-06-10T09:09:28Z

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"
  }
}

The text was updated successfully, but these errors were encountered:

frozeman · 2015-06-10T09:27:26Z

Thanks for that find 👍

tgerring · 2015-06-15T13:56:26Z

@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 · 2015-06-15T14:40:07Z

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 · 2015-06-16T08:12:36Z

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

tgerring · 2015-06-16T22:28:58Z

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 · 2015-06-16T22:41:07Z

@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 · 2015-06-18T11:39:26Z

@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 · 2015-06-18T11:55:57Z

@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 · 2015-06-18T14:20:33Z

@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 · 2015-06-18T21:20:11Z

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 · 2015-06-19T03:35:51Z

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.

tgerring · 2015-06-19T09:54:39Z

My vote would be for log index to be the order of the logs within each transaction. For most transactions that trigger only a single log, this value would be 0. When more than 1 log is triggered in a single transaction, it would increment by 1.

Combined with the TxIndex, the order of logs in a block should always be consistent when sorted by the key set (TxIndex, LogIndex). This change may be "harder" but I believe to be more semantically correct.

frozeman · 2015-06-19T11:27:00Z

I agree log index should be the index of the log within a transaction. So agree to what you described @tgerring

Because this will make specially sense if we have eth_getReceipt working

tgerring · 2015-07-09T14:59:50Z

develop HEAD log index is not correct:

$ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x194bdf917c9bb213e1391c0172aaf63c8e0014006040b8bf627e285b67d8f81f"],"id":1}' http://127.0.0.1:8545
{
    "id": 1,
    "jsonrpc": "2.0",
    "result": {
        "transactionHash": "0x194bdf917c9bb213e1391c0172aaf63c8e0014006040b8bf627e285b67d8f81f",
        "transactionIndex": "0x0",
        "blockNumber": "0xcd5be",
        "blockHash": "0x852c1440f950ffa8e83a16eda2ffd99569b68e4a46ebcff4547535ea75658f00",
        "cumulativeGasUsed": "0xc7e6",
        "gasUsed": "0xc7e6",
        "contractAddress": null,
        "logs": [
            {
                "address": "0x21a3a128968f7fd17eb0a16045a84769374aeae0",
                "topics": [
                    "0xe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda"
                ],
                "data": "0x000000000000000000000000e6716f9544a56c530d868e4bfbacb172315bdead9aecddd4c1227f08f3ea847ffebcd1204b54a97f95c9e16749f80ae5e92c3f4a",
                "blockNumber": "0xcd5be",
                "logIndex": "0x0",
                "blockHash": "0x852c1440f950ffa8e83a16eda2ffd99569b68e4a46ebcff4547535ea75658f00",
                "transactionHash": "0x194bdf917c9bb213e1391c0172aaf63c8e0014006040b8bf627e285b67d8f81f",
                "transactionIndex": "0x0"
            },
            {
                "address": "0x21a3a128968f7fd17eb0a16045a84769374aeae0",
                "topics": [
                    "0xe7c957c06e9a662c1a6c77366179f5b702b97651dc28eee7d5bf1dff6e40bb4a"
                ],
                "data": "0x000000000000000000000000e6716f9544a56c530d868e4bfbacb172315bdead9aecddd4c1227f08f3ea847ffebcd1204b54a97f95c9e16749f80ae5e92c3f4a0000000000000000000000000000000000000000000000000000000000000539000000000000000000000000deadbeefdeadbeefdeadbeefdeadbeefdeadbeef00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000005686f727365000000000000000000000000000000000000000000000000000000",
                "blockNumber": "0xcd5be",
                "logIndex": "0x0",
                "blockHash": "0x852c1440f950ffa8e83a16eda2ffd99569b68e4a46ebcff4547535ea75658f00",
                "transactionHash": "0x194bdf917c9bb213e1391c0172aaf63c8e0014006040b8bf627e285b67d8f81f",
                "transactionIndex": "0x0"
            }
        ]
    }
}
``

frozeman · 2015-07-09T15:43:19Z

👍 But i think this belongs into its own issue. (But it internally might be connected)

debris · 2015-07-29T11:54:34Z

I see that the problem is still not resolved. Any update on this?

obscuren · 2015-07-29T12:19:49Z

See #1545

Two transactions:

I0729 14:31:38.192576   76759 xeth.go:957] Tx(0x3cf2e0931be45fa6432e49fc8ffd712add6de715ed158a93609a5e4d5cd77389) to: 0x9e580a8ccbb94adf1cc149d7aae7963f0a9ddc47
I0729 14:31:43.935750   76759 xeth.go:957] Tx(0x024d89dcb9a6f7b3e7108b4bbd84a224215c894f5a214d3c9bca84dd8fe33054) to: 0x9e580a8ccbb94adf1cc149d7aae7963f0a9ddc47

First transaction creates 1 log, second transaction creates 2 (multi sig). Both logs are mined in the same block.

> eth.getTransactionReceipt("0x3cf2e0931be45fa6432e49fc8ffd712add6de715ed158a93609a5e4d5cd77389")
{
  blockHash: '0x080fc005a6bb5c4266027c5bd80532859550e3c28340d80496f8898f9fedfc92',
  blockNumber: 759,
  contractAddress: Error: Cannot access member 'constructor' of null,
  cumulativeGasUsed: 171506,
  gasUsed: 171506,
  logs: [{
    address: '0x9e580a8ccbb94adf1cc149d7aae7963f0a9ddc47',
    blockHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
    blockNumber: 759,
    data: '0x000000000000000000000000cda0ad7542e30bf520652a05056ebe0105c7e49a3baca99d3af36a48980f01c416bff85d4a834067f3115378b9d36315fd30bb44',
    logIndex: 0,
    topics: ['0xe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda' ],
    transactionHash: '0x3cf2e0931be45fa6432e49fc8ffd712add6de715ed158a93609a5e4d5cd77389',
    transactionIndex: 0
  }, {
    address: '0x9e580a8ccbb94adf1cc149d7aae7963f0a9ddc47',
    blockHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
    blockNumber: 759,
    data: '0x3baca99d3af36a48980f01c416bff85d4a834067f3115378b9d36315fd30bb44000000000000000000000000cda0ad7542e30bf520652a05056ebe0105c7e49a00000000000000000000000000000000000000000000000098a7d9b8314c0000000000000000000000000000cda0ad7542e30bf520652a05056ebe0105c7e49a00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000',
    logIndex: 1,
    topics: ['0x1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf32' ],
    transactionHash: '0x3cf2e0931be45fa6432e49fc8ffd712add6de715ed158a93609a5e4d5cd77389',
    transactionIndex: 0
  } ],
  transactionHash: '0x3cf2e0931be45fa6432e49fc8ffd712add6de715ed158a93609a5e4d5cd77389',
  transactionIndex: 0
}
> eth.getTransactionReceipt("0x024d89dcb9a6f7b3e7108b4bbd84a224215c894f5a214d3c9bca84dd8fe33054")
{
  blockHash: '0x080fc005a6bb5c4266027c5bd80532859550e3c28340d80496f8898f9fedfc92',
  blockNumber: 759,
  contractAddress: Error: Cannot access member 'constructor' of null,
  cumulativeGasUsed: 210724,
  gasUsed: 39218,
  logs: [{
    address: '0x9e580a8ccbb94adf1cc149d7aae7963f0a9ddc47',
    blockHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
    blockNumber: 759,
    data: '0x000000000000000000000000cda0ad7542e30bf520652a05056ebe0105c7e49a0000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000cda0ad7542e30bf520652a05056ebe0105c7e49a00000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000',
    logIndex: 2,
    topics: ['0x92ca3a80853e6663fa31fa10b99225f18d4902939b4c53a9caae9043f6efd004' ],
    transactionHash: '0x024d89dcb9a6f7b3e7108b4bbd84a224215c894f5a214d3c9bca84dd8fe33054',
    transactionIndex: 0
  } ],
  transactionHash: '0x024d89dcb9a6f7b3e7108b4bbd84a224215c894f5a214d3c9bca84dd8fe33054',
  transactionIndex: 1
}

frozeman · 2015-07-29T12:22:09Z

:1 but array start with 0, so the log index should start with 0 too, so you can map it to the right log for example.

frozeman · 2015-07-29T12:23:32Z

Ah is see. Actual the log index should be a representation of the index in the receipts array IMO, otherwise i'm not sure what this log index is supposed to be used for. (rather than mapping it to the right log in a receipt)

Or is there any other use for knowing that log x came after log y? I can see it be useful, but then you can't map logs anymore back to its receipts position.

obscuren · 2015-07-29T12:33:24Z

It was wrong. I'm updating the comment now

frozeman · 2015-07-29T12:35:49Z

Ok, you changed the receipt position. So what is now the correct index? with what are we going?

logIndex == pos in receipt
or
logIndex == pos of log in this contract in this block
?

tgerring · 2015-07-29T12:39:05Z

I thought we had discussed above that logIndex was the log position within the receipt, so as to distinguish multiple logs firing as the result of the same transaction

core/state: Set log index. Closes #1226

) * go.mod: update golang.org/x/crypto to fix a Go 1.14 race rejection Cherry-pick conflicts: go.mod go.sum * p2p/discv5: fix test on go 1.14 (ethereum#20724) Cherry-picked to celo-blockchain * travis, appveyor, build, Dockerfile: bump Go to 1.14.2 (ethereum#20913) * travis, appveyor, build, Dockerfile: bump Go to 1.14.2 * travis, appveyor: force GO111MODULE=on for every build Cherry-pick conflicts: .travis.yml appveyor.yml build/checksums.txt * Update CircleCI and dockerfiles to use Go 1.14 * Revert ios build CI config to work with Go 1.13 * Update golang download links to 1.14.12 Co-authored-by: Péter Szilágyi <[email protected]> Co-authored-by: Felix Lange <[email protected]> Co-authored-by: Péter Szilágyi <[email protected]> Co-authored-by: Felix Lange <[email protected]>

…ereum#1226) * eth: fix a rare datarace on CHT challenge reply / shutdown * trie: check childrens' existence concurrently for snap heal * eth/protocols/snap: fix problems due to idle-but-busy peers * eth/filters: change filter block to be by-ref (ethereum#26054) This PR changes the block field in the filter to be a pointer, to disambiguate between empty hash and no hash * rpc: handle wrong HTTP batch response length (ethereum#26064) * eth/protocols/snap: throttle trie heal requests when peers DoS us (ethereum#25666) * eth/protocols/snap: throttle trie heal requests when peers DoS us * eth/protocols/snap: lower heal throttle log to debug Co-authored-by: Martin Holst Swende <[email protected]> * eth/protocols/snap: fix comment Co-authored-by: Martin Holst Swende <[email protected]> Co-authored-by: Péter Szilágyi <[email protected]> Co-authored-by: Martin Holst Swende <[email protected]> Co-authored-by: Jordan Krage <[email protected]>

frozeman added type:bug RPC labels Jun 10, 2015

obscuren modified the milestone: 0.9.32 Jun 15, 2015

obscuren modified the milestones: 0.9.32, 0.9.34 Jun 23, 2015

tgerring self-assigned this Jun 23, 2015

obscuren modified the milestone: 0.9.34 Jun 30, 2015

obscuren assigned obscuren and unassigned tgerring Jul 29, 2015

obscuren added the in progress label Jul 29, 2015

obscuren added a commit to obscuren/go-ethereum that referenced this issue Jul 29, 2015

core/state: Set log index. Closes ethereum#1226

f715547

obscuren mentioned this issue Jul 30, 2015

core/state: Set log index. Closes #1226 #1545

Merged

obscuren added a commit that referenced this issue Jul 31, 2015

Merge pull request #1545 from obscuren/log-index

ab85a35

core/state: Set log index. Closes #1226

obscuren closed this as completed Sep 23, 2015

obscuren removed the in progress label Sep 23, 2015

frozeman mentioned this issue Mar 9, 2016

eth: add subscription for logs #2200

Closed

adamschmideg added the area:rpc label Dec 14, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RPC] incorrect logIndex in logs received from eth_getfilterchanges #1226

[RPC] incorrect logIndex in logs received from eth_getfilterchanges #1226

debris commented Jun 10, 2015

frozeman commented Jun 10, 2015

tgerring commented Jun 15, 2015

obscuren commented Jun 15, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 18, 2015

frozeman commented Jun 18, 2015

tgerring commented Jun 18, 2015

frozeman commented Jun 18, 2015

debris commented Jun 19, 2015

tgerring commented Jun 19, 2015

frozeman commented Jun 19, 2015

tgerring commented Jul 9, 2015

frozeman commented Jul 9, 2015

debris commented Jul 29, 2015

obscuren commented Jul 29, 2015

frozeman commented Jul 29, 2015

frozeman commented Jul 29, 2015

obscuren commented Jul 29, 2015

frozeman commented Jul 29, 2015

tgerring commented Jul 29, 2015

[RPC] incorrect logIndex in logs received from eth_getfilterchanges #1226

[RPC] incorrect logIndex in logs received from eth_getfilterchanges #1226

Comments

debris commented Jun 10, 2015

frozeman commented Jun 10, 2015

tgerring commented Jun 15, 2015

obscuren commented Jun 15, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 16, 2015

tgerring commented Jun 18, 2015

frozeman commented Jun 18, 2015

tgerring commented Jun 18, 2015

frozeman commented Jun 18, 2015

debris commented Jun 19, 2015

tgerring commented Jun 19, 2015

frozeman commented Jun 19, 2015

tgerring commented Jul 9, 2015

frozeman commented Jul 9, 2015

debris commented Jul 29, 2015

obscuren commented Jul 29, 2015

frozeman commented Jul 29, 2015

frozeman commented Jul 29, 2015

obscuren commented Jul 29, 2015

frozeman commented Jul 29, 2015

tgerring commented Jul 29, 2015