Wrong blockchain data

[peterbitfly]

My fully synced parity node (latest beta branch) returns an invalid block & tx combo:

web3.eth.getTransactionReceipt("0x963021948f4df6980edb20dd559f5ce472d797aa8ff27214f5e6e32aeadf9fc9")
{ blockHash: '0x2bc9d7cef8ae9b4b175fec5c7f91237ba1b8d17e9eb8f886b15b6d04c1c6c4bb',
blockNumber: 2331557,
contractAddress: null,
cumulativeGasUsed: 839890,
gasUsed: 21000,
logs: [],
transactionHash: '0x963021948f4df6980edb20dd559f5ce472d797aa8ff27214f5e6e32aeadf9fc9',
transactionIndex: 30 }

Also we are observing lots of tx that go missing and are not mined at all. Please advice how to proceed as this failures makes it impossible to use parity to send transactions in a reliable way.

[peterbitfly]

Another example:

web3.eth.getTransactionReceipt("0x6cf7d00b5776a12f761274cd3810ab6d94bc9f0920f8419871d74fb16b95d8f2")
{ blockHash: '0xac16e1f9aa97a466f96bc7218db3dbdd551742bc11395d74813adac9b6874d0a',
blockNumber: 2333810,
contractAddress: null,
cumulativeGasUsed: 194700,
gasUsed: 21000,
logs: [],
transactionHash: '0x6cf7d00b5776a12f761274cd3810ab6d94bc9f0920f8419871d74fb16b95d8f2',
transactionIndex: 8 }

web3.eth.getBlock("2333810")
{ author: '0xbcdfc35b86bedf72f0cda046a3c16829a2ef41d1',
difficulty: { [String: '72091976892359'] s: 1, e: 13, c: [ 72091976892359 ] },
extraData: '0x7777772e62772e636f6d',
gasLimit: 1499247,
gasUsed: 0,
hash: '0xdaff4f3a9fc2bd959e536c3b5ab13d098f9bb7e1f35a0ae1f32e38a06dfc3182',
logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
miner: '0xbcdfc35b86bedf72f0cda046a3c16829a2ef41d1',
number: 2333810,
parentHash: '0x53b2e65a8678352460ce81c239883492f93116dda0f0242219b8ae3ed68038e0',
receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',
sealFields:
[ '0x10f6c07ad972aa8c76c3ac1bbf141e59288ba5cbe98282e540fcf2adec15adbd',
'0x2a8d92700fbd7b19' ],
sha3Uncles: '0x4653213a5013d82f73729b5d664a410402b8d51fe4083d4aec4a360e836c136b',
size: 1051,
stateRoot: '0xc4f7f6a7772bc4d955d9a68128d6162c335b58a01d33e267fdee593892a5ca60',
timestamp: 1474945790,
totalDifficulty: { [String: '66027578792837048503'] s: 1, e: 19, c: [ 660275, 78792837048503 ] },
transactions: [],
transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',
uncles: [ '0x8f2cb58e88790a89c8fa05a33313923560cac5abd47a9a84923a8d011701ea8e' ] }

[debris]

Which version of parity are you using? we recently fixed issue which could cause similar symptoms

[peterbitfly]

I tried latest beta and version 1.3.1, both show the same symptoms.

[tomusdrw]

There are two pending PRs fixing the issue(s):

1. Prioritizing re-imported transactions #2372 - Transactions from retracted blocks will have higher priority in the queue (before if queue was full they could have been discarded)
2. Removing extras data from retracted blocks. #2375 - Fixes a bug when block becomes a fork, transaction data was still available (and it shouldn't).

[peterbitfly]

Ok, thx, will the PRs be backported to beta as well?

[tomusdrw]

Yes, we are planning to release 1.3.2. shortly and those will be part of that release.

[peterbitfly]

ok, perfect, I will re-test once the pr's are merged

[tomusdrw]

Released in 1.3.2, also part of master branch.

[peterbitfly]

In light of the recent spam attack I am seeing again tx getting lost in limbo with the same behavior described above. All on the latest parity master.

[tomusdrw]

Can you try increasing the transaction queue size --tx-queue-size 4096? Transactions are prioritized but only within same "nonce height (tx_nonce - state_nonce)" - if there are many transactions pending some of the transactions with larger nonce height might be discarded because of the limit.