Parity Node: Could not find balance for token decrease

[ghost]

Parity node running without any particular option.

Error displayed in Augur UI:
"ERROR: Could not find balance for token decrease (token: 0xSOMEADDRESS, owner: 0xSOMEOTHERADDRESS)."

Judging by the upvotes, others are facing the same trouble:
https://np.reddit.com/r/Augur/comments/94rv08/error_when_running_with_local_parity_node/

[petervecchiarelli]

https://app.clubhouse.io/augur/story/15116/github-parity-node-could-not-find-balance-for-token-decrease

[ghost]

what's that @petervecchiarelli ?

[petervecchiarelli]

@GustavMarwin just means it's been added to the issue tracker :)

[bthaile]

@GustavMarwin have you tried with new version of augur-app we added a lag so we can process log data with more integrity.

If you are not using augur-app then can you clarify your setup?

[ghost]

@bthaile I have just tried the latest version and experience the same exact issue.

My setup is the latest versions of MacOS, Augur and Parity running on a remote server used the following way:

On my dedicated server I run "parity --ws-origins=all --ws-apis=all,-personal --ws-hosts=all"
On my local computer I run "ssh -L 8545:127.0.0.1:8545 -L 8546:127.0.0.1:8546 user@server_ip"

I'd like to mention that I am not sure what flags are required on Parity so I open up my parity node probably more than necessary, ideally I would really like to restrict that.

Thank you.

[epheph]

@GustavMarwin can you run this curl command?

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ {"fromBlock":"0x5a6da7","toBlock":"0x5a6da7","address":"0x75228dce4d82566d93068a8d5d49435216551599","topics":[["0xbaba17e31bb9fbfbc0b794111d2b1236ed4e36067a5e0d7c3c3433ad66c99f9d","0x0bffe152251da36b8f0264e3db7a5194b0cae63e5a6cbcf89b753c10ffbe068d","0xdd0dca2d338dc86ba5431017bdf6f3ad45247d608b0a38d866e3131a876be2cc","0xee62c58e2603b92f96a002e012f4f3bd5748102cfa3b711f6d778c6237fcaa96","0xb2e65de73007eef46316e4f18ab1f301b4d0e31aa56733387b469612f90894df","0x8a34ec183bf620d74d0b52e71165bb4255b0591d1c8e9d07c707a7f1d763158d","0xc3cf07f8fa0fafc25a9dd0bad2cd6b961c55dad41b42c8ef8f931bc40e41e08c","0x014ce4e12965529d7d31e11411d7a23b1778d448ab763ffc4d55830cbb4919d7","0x513d029ff62330c16d8d4b36b28fab53f09d10bb51b56fe121ab710ca2d1af80","0x32d554e498d0c7f2a5c7fd8b6b234bfc4e1dfb5290466d998af09a813db32f31","0xabb970462c1f0de9e237d127ad47c01c4e69caa179fd850d076ae9bfc529176e","0xccc07058358a9411a6acb3cd58bf6d0b398c3ff1f0b2c8e97a6dbdbbe74eae41","0xa340b40e5e280037f25da1bff4a1b4030d764649f0d5029a2198182c42cff883","0xec05f094139821aeb3220a0837f5d14eb02aa619179aadf3b316ed95b3648abb","0xb20adf682c8f82b94a135452f54ac4483c9ee8c9b2324e946120696ab1d034b4","0x262b80f2af08a1001d15a1df91dde9acb8441811543886659b3845a8c285748b","0x75dd618f69c0f07adc97fe19ba435f3932ce6aa8cad287fb9bdfaf37639f703a","0x3c67396e9c55d2fc8ad68875fc5beca1d96ad2a2f23b210ccc1d986551ab6fdf","0xa7e9373569caad2b7871ecb4d498619fc1c42840a6c0dbeb8dff20b131721e50","0x299eaafd0d27519eda3fe7195b73e5269e442b3d80928f19afa32b6db2f352b6","0xd4d990bbdf9b9a4383a394341465060ccb75513432ceee3d5fcd8788ab1a507f","0xc62cff53848fe243adb6130140cfe557ce16e8006861abd50adfe425150ba6c5","0x450bd662d3b1e236c8f344457690d257aeae5dca1add336752839ac206613cc0","0x11dda748f0bd3af85a073da0088a0acb827d9584a4fdb825c81f1232a5309538","0x349ab20f76ba930a00da1936627d07400af6bb7cd2e2b4c68bcab93ca8aff418","0x68166bb2a567c21899b00209f52c286bf00ac613acc9f183da791ac5f5f47051","0x3b4f3db017516414df2695e5b0052661779d7163a6cd4368fd74313be73fa0b8"]]} ],"id":74}' localhost:8545

This will get logs from an old block. I've seen some pruning styles not have the logs going that far back. You'll know there's a problem if it is

{"jsonrpc":"2.0","result":[],"id":74}

[ghost]

I now know there is a problem: {"jsonrpc":"2.0","result":[],"id":74}

ahhhhh I get it... so that's clearly something that should be addressed though, many more people must have faced, or at least will face the same issue. How far back is a Parity node supposed to go? Is there a way to "ask" a parity node to get the necessary data? Or even a way to sync parity from scratch and specify a data point from which not to prune? Essentially what's the right way to use Parity when also using Augur. Thanks!!

[epheph]

Yes, we will be releasing recommended options for running parity.

What version of parity?

[ghost]

1.11.7-stable-085035fa2-20180717

[matteopey]

I have this exact issue on latest:
Parity-Ethereum/v2.0.1-beta-e7dc0bed1-20180726/x86_64-windows-msvc/rustc1.27.2
@GustavMarwin did you solve the problem?

[andresilva]

I think this could be two things:

1. If you warp synced it's possible your node is still downloading ancient blocks and therefore doesn't have the data available to reply correctly. Currently it replies with an empty result (there's an issue to improve this: Warn when reading date from non-existing ancient blocks. openethereum/parity-ethereum#7411).
2. We had a bug recently related to the storage of blooms when re-orgs happened, which could lead to the incorrect construction of blooms (blooms in parity-ethereum are stored in a "hierarchical" structure for performance reasons). This is already fixed but if your local blooms data was already in an invalid state it will stay broken.

In case you're running with the same database for a while it's possible you're affected by no. 2 (that seemed to be the case for @matteopey), could you try syncing from scratch?

[epheph]

Could anyone who is having an issue with the above getLogs returning [] try running this curl?

curl --data '{"method":"eth_getTransactionReceipt","params":["0x44c09f8eeff886723b79890e14743192a8c8d8a8eac158ed17600c94e502cce8"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

[matteopey]

It works. I can make any API calls to any transaction on any blocks as long as filtering logs is not involved.

{
   "jsonrpc":"2.0",
   "result":{
      "blockHash":"0x4ff6030cce082be8f5a56d7f7bbe5e32e8d98295f31c8e070285fbdd022a06a7",
      "blockNumber":"0x5a6da7",
      "contractAddress":null,
      "cumulativeGasUsed":"0x1b91eb",
      "from":"0xd82369aaec27c7a749afdb4eb71add9e64154cd6",
      "gasUsed":"0xb74f3",
      "logs":[
         {
            "address":"0x75228dce4d82566d93068a8d5d49435216551599",
            "blockHash":"0x4ff6030cce082be8f5a56d7f7bbe5e32e8d98295f31c8e070285fbdd022a06a7",
            "blockNumber":"0x5a6da7",
            "data":"0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "logIndex":"0x9",
            "removed":false,
            "topics":[
               "0x299eaafd0d27519eda3fe7195b73e5269e442b3d80928f19afa32b6db2f352b6",
               "0x0000000000000000000000000000000000000000000000000000000000000000",
               "0x000000000000000000000000e991247b78f937d7b69cfc00f1a487a293557677"
            ],
            "transactionHash":"0x44c09f8eeff886723b79890e14743192a8c8d8a8eac158ed17600c94e502cce8",
            "transactionIndex":"0x2a",
            "transactionLogIndex":"0x0",
            "type":"mined"
         }
      ],
      "logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000004000000000800000000000000000000000000000000000010000000080000000020000000000000004000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000008000000000000000021000000000000000000000000000000000000000000000000000000000000000000",
      "root":null,
      "status":"0x1",
      "to":"0x75228dce4d82566d93068a8d5d49435216551599",
      "transactionHash":"0x44c09f8eeff886723b79890e14743192a8c8d8a8eac158ed17600c94e502cce8",
      "transactionIndex":"0x2a"
   },
   "id":1
}                                                                                                                                                  

[epheph]

@matteopey and when you run the above getLogs:

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ {"fromBlock":"0x5a6da7","toBlock":"0x5a6da7","address":"0x75228dce4d82566d93068a8d5d49435216551599","topics":[["0xbaba17e31bb9fbfbc0b794111d2b1236ed4e36067a5e0d7c3c3433ad66c99f9d","0x0bffe152251da36b8f0264e3db7a5194b0cae63e5a6cbcf89b753c10ffbe068d","0xdd0dca2d338dc86ba5431017bdf6f3ad45247d608b0a38d866e3131a876be2cc","0xee62c58e2603b92f96a002e012f4f3bd5748102cfa3b711f6d778c6237fcaa96","0xb2e65de73007eef46316e4f18ab1f301b4d0e31aa56733387b469612f90894df","0x8a34ec183bf620d74d0b52e71165bb4255b0591d1c8e9d07c707a7f1d763158d","0xc3cf07f8fa0fafc25a9dd0bad2cd6b961c55dad41b42c8ef8f931bc40e41e08c","0x014ce4e12965529d7d31e11411d7a23b1778d448ab763ffc4d55830cbb4919d7","0x513d029ff62330c16d8d4b36b28fab53f09d10bb51b56fe121ab710ca2d1af80","0x32d554e498d0c7f2a5c7fd8b6b234bfc4e1dfb5290466d998af09a813db32f31","0xabb970462c1f0de9e237d127ad47c01c4e69caa179fd850d076ae9bfc529176e","0xccc07058358a9411a6acb3cd58bf6d0b398c3ff1f0b2c8e97a6dbdbbe74eae41","0xa340b40e5e280037f25da1bff4a1b4030d764649f0d5029a2198182c42cff883","0xec05f094139821aeb3220a0837f5d14eb02aa619179aadf3b316ed95b3648abb","0xb20adf682c8f82b94a135452f54ac4483c9ee8c9b2324e946120696ab1d034b4","0x262b80f2af08a1001d15a1df91dde9acb8441811543886659b3845a8c285748b","0x75dd618f69c0f07adc97fe19ba435f3932ce6aa8cad287fb9bdfaf37639f703a","0x3c67396e9c55d2fc8ad68875fc5beca1d96ad2a2f23b210ccc1d986551ab6fdf","0xa7e9373569caad2b7871ecb4d498619fc1c42840a6c0dbeb8dff20b131721e50","0x299eaafd0d27519eda3fe7195b73e5269e442b3d80928f19afa32b6db2f352b6","0xd4d990bbdf9b9a4383a394341465060ccb75513432ceee3d5fcd8788ab1a507f","0xc62cff53848fe243adb6130140cfe557ce16e8006861abd50adfe425150ba6c5","0x450bd662d3b1e236c8f344457690d257aeae5dca1add336752839ac206613cc0","0x11dda748f0bd3af85a073da0088a0acb827d9584a4fdb825c81f1232a5309538","0x349ab20f76ba930a00da1936627d07400af6bb7cd2e2b4c68bcab93ca8aff418","0x68166bb2a567c21899b00209f52c286bf00ac613acc9f183da791ac5f5f47051","0x3b4f3db017516414df2695e5b0052661779d7163a6cd4368fd74313be73fa0b8"]]} ],"id":74}' localhost:8545

you get a [] response? I have a suspicion that you will get a response to that query now. What parity version?

[epheph]

I have what seems like might be a different issue. I just warp-sync'd a brand new parity (version: v1.11.7 ) and here is the behavior I am seeing:

$ curl -s --data '{"method":"eth_getBlockByNumber","params":["0x5f8521",false],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 | jq .result.hash
"0x94fe6e790feff863ab7b4d40458544a25ea67a2d1680fb7d9dd07f18144de9a4"

$ curl --data '{"method":"eth_getBlockByNumber","params":["0x5f8520",false],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
{"jsonrpc":"2.0","result":null,"id":1}

It returns "null" for a getBlock of 6260000, but returns the block properly for 6260001.
This is strange behavior. My understanding was that even a light node should respond to getBlocks requests for old blocks. This one is only 2 days old.

[Tbaut]

I just warp-sync'd

what was the first blocks you were syncing normally after the warp sync? It could very well be 6260001.
Warp sync is simply giving you the snapshot of the state of a node. Normal sync will resume from this block on and in the future your node will download and verify all the remaining blocks (from the snapshot block until the genesis). But this can take a while.

My understanding was that even a light node should respond to getBlocks requests

A light node is something else, a full node that is warp-syncing is not a light node. So yes a light node should answer to getBlock, but what you have is a full node that is not fully synced yet.

[epheph]

@Tbaut you are correct, 6260001 is my warp-barrier. So this is what has caused such issue with augur and parity, when someone warp sync's, that warp-barrier is beyond the upload block number. Augur-node issues a getBlockByNumber("latest") and begins sync'ing up to this point, but receives [] for all getLogs requests up to that warp barrier. It is receiving partial information, and parity is giving the rpc call no information to indicate that it has requested something that is not yet available.

[matteopey]

@epheph With getLogs on old blocks I get empty result.

$ curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ {"fromBlock":"0x5a6da7","toBlock":"0x5a6da7","address":"0x75228dce4d82566d93068a8d5d49435216551599","topics":[["0xbaba17e31bb9fbfbc0b794111d2b1236ed4e36067a5e0d7c3c3433ad66c99f9d","0x0bffe152251da36b8f0264e3db7a5194b0cae63e5a6cbcf89b753c10ffbe068d","0xdd0dca2d338dc86ba5431017bdf6f3ad45247d608b0a38d866e3131a876be2cc","0xee62c58e2603b92f96a002e012f4f3bd5748102cfa3b711f6d778c6237fcaa96","0xb2e65de73007eef46316e4f18ab1f301b4d0e31aa56733387b469612f90894df","0x8a34ec183bf620d74d0b52e71165bb4255b0591d1c8e9d07c707a7f1d763158d","0xc3cf07f8fa0fafc25a9dd0bad2cd6b961c55dad41b42c8ef8f931bc40e41e08c","0x014ce4e12965529d7d31e11411d7a23b1778d448ab763ffc4d55830cbb4919d7","0x513d029ff62330c16d8d4b36b28fab53f09d10bb51b56fe121ab710ca2d1af80","0x32d554e498d0c7f2a5c7fd8b6b234bfc4e1dfb5290466d998af09a813db32f31","0xabb970462c1f0de9e237d127ad47c01c4e69caa179fd850d076ae9bfc529176e","0xccc07058358a9411a6acb3cd58bf6d0b398c3ff1f0b2c8e97a6dbdbbe74eae41","0xa340b40e5e280037f25da1bff4a1b4030d764649f0d5029a2198182c42cff883","0xec05f094139821aeb3220a0837f5d14eb02aa619179aadf3b316ed95b3648abb","0xb20adf682c8f82b94a135452f54ac4483c9ee8c9b2324e946120696ab1d034b4","0x262b80f2af08a1001d15a1df91dde9acb8441811543886659b3845a8c285748b","0x75dd618f69c0f07adc97fe19ba435f3932ce6aa8cad287fb9bdfaf37639f703a","0x3c67396e9c55d2fc8ad68875fc5beca1d96ad2a2f23b210ccc1d986551ab6fdf","0xa7e9373569caad2b7871ecb4d498619fc1c42840a6c0dbeb8dff20b131721e50","0x299eaafd0d27519eda3fe7195b73e5269e442b3d80928f19afa32b6db2f352b6","0xd4d990bbdf9b9a4383a394341465060ccb75513432ceee3d5fcd8788ab1a507f","0xc62cff53848fe243adb6130140cfe557ce16e8006861abd50adfe425150ba6c5","0x450bd662d3b1e236c8f344457690d257aeae5dca1add336752839ac206613cc0","0x11dda748f0bd3af85a073da0088a0acb827d9584a4fdb825c81f1232a5309538","0x349ab20f76ba930a00da1936627d07400af6bb7cd2e2b4c68bcab93ca8aff418","0x68166bb2a567c21899b00209f52c286bf00ac613acc9f183da791ac5f5f47051","0x3b4f3db017516414df2695e5b0052661779d7163a6cd4368fd74313be73fa0b8"]]} ],"id":74}' localhost:8545
{"jsonrpc":"2.0","result":[],"id":74}

I use Parity 2.0.1, and that's the problem. As andresilva said, the database got corrupted in the migration from the old Parity 1.11 to 2.0.1. This behavior happens for any getLogs call on any block prior to the migration.
For recent blocks everything works fine, for example:

$ curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ {"fromBlock":"0x5FB6FD","toBlock":"0x5FB6FD","address":"0x75228dce4d82566d93068a8d5d49435216551599"} ],"id":74}' localhost:8545
{
   "jsonrpc":"2.0",
   "result":[
      {
         "address":"0x75228dce4d82566d93068a8d5d49435216551599",
         "blockHash":"0x050c6b16d442df898819049195e914c7e8c91f28d5d41847f887e961e7ac13db",
         "blockNumber":"0x5fb6fd",
         "data":"0x0000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be00000000000000000000000000000000000000000000002b4351d8cfc2979c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
         "logIndex":"0x1c",
         "removed":false,
         "topics":[
            "0x3c67396e9c55d2fc8ad68875fc5beca1d96ad2a2f23b210ccc1d986551ab6fdf",
            "0x000000000000000000000000e991247b78f937d7b69cfc00f1a487a293557677",
            "0x0000000000000000000000001985365e9f78359a9b6ad760e32412f4a445e862",
            "0x00000000000000000000000040120b5a5994f7e3afe3c0a3dc56d1ccb0b75262"
         ],
         "transactionHash":"0x38d6b72172127958713a04811379e02820ce15b545b6dc41d310a8883a002478",
         "transactionIndex":"0x2c",
         "transactionLogIndex":"0x1",
         "type":"mined"
      }
   ],
   "id":74
}

I'm in the process of resyncing again (without warp-sync) on another PC, and with very old blocks it already works as intended.

[epheph]

OK, it's possible your parity 2.0 installation was just in the middle of a warp sync. That is the exact behavior we have been witnessing (that @Tbaut mentioned). When you warp sync, your Ethereum node has a "gap" in its knowledge (and does not respond in a way that indicates there was a problem, just says [] "nothing was there"). It is doing a background refresh of blocks previous to your warp barrier, starting at 0, so things that are very recent will be there, and less recent will not. And then if you go far enough back, to where it is performing the background "ancient" block downloads, there will be log/block data again.

[Tbaut]

You guys have 2 different problems, that André explained. @matteopey is the victim of a bug (that got fixed) and @epheph is the victim of time and the absence of error. Your node hasn't had time to do a full sync while the RPC answers nothing whereas it should more elegantly answer with an error (openethereum/parity-ethereum#7411)

[adrake33]

Closing since the error handling for this has been improved. More info is at https://github.com/AugurProject/augur-app#parity-and-warp-sync.