transaction_pool::pool [0x...] Ignoring Future transaction.

[jcortejoso]

Before filing a new issue, please provide the following information.

• Parity Ethereum version: 2.2.0 (commit f8f8bf0)
• Operating system: Linux
• Installation: built from source
• Fully synchronized: yes
• Network: private PoA
• Restarted:

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

We have set up a PoA network with 3 authorities nodes, and also configured with parity secret store enabled. We can join to the network from outside and we can make transactions using rpc calls, metamask...
The problem is related with transactions made by a contract. We generate a transaction data offchain, and then we send this transaction to the rpc interface of a node connected to this PoA network. The problem is that the transaction is ignored by the network/nodes with the next log.

The transaction not mined and the log shows:

...
2018-12-12 08:54:49 UTC Verifier #1 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:54:50 UTC IO Worker #3 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:55:35 UTC Verifier #3 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:55:35 UTC IO Worker #1 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:56:39 UTC Verifier #0 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:56:39 UTC IO Worker #2 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
2018-12-12 08:56:52 UTC Verifier #1 TRACE transaction_pool::pool  [0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6] Ignoring Future transaction.
...

The information of the transaction is:

{
  "jsonrpc": "2.0",
  "result": {
    "blockHash": null,
    "blockNumber": null,
    "chainId": "0x2323",
    "condition": null,
    "creates": null,
    "from": "0x0e364eb0ad6eb5a4fc30fc3d2c2ae8ebe75f245c",
    "gas": "0x44a9a",
    "gasPrice": "0x2540be400",
    "hash": "0x5f3e47e313fb1acbace89de5456785387bce860672aba9f60f296abcce7233f6",
    "input": "0x995b2cff0000000000000000000000000e364eb0ad6eb5a4fc30fc3d2c2ae8ebe75f245c0000000000000000000000000000000000000000000000000de0b6b3a7640000cb3f7ba3352f77081d5d52dd0f2d6af81c7424f5366a5ec933fe4257eb2b88c0",
    "nonce": "0x48",
    "publicKey": "0xd73905a85de3ea9686618e5034c73dfe5f6b24a477514726b8a0a581cbcdbca091df840ea7c88e047d939c0a86dbee3514726e8892c7960aba8853dcc3b0565e",
    "r": "0xa6bb22b7e82f0d05f03a118f77ad0d81a8b9ef988564eb1bb994a7b19b2ae8c3",
    "raw": "0xf8cc488502540be40083044a9a94642339c00133e27e6021968dd9e8304f9fab734880b864995b2cff0000000000000000000000000e364eb0ad6eb5a4fc30fc3d2c2ae8ebe75f245c0000000000000000000000000000000000000000000000000de0b6b3a7640000cb3f7ba3352f77081d5d52dd0f2d6af81c7424f5366a5ec933fe4257eb2b88c0824669a0a6bb22b7e82f0d05f03a118f77ad0d81a8b9ef988564eb1bb994a7b19b2ae8c3a053e15f0806b30399d63890783880f61bad387c6040afd231a044f047ca025b4d",
    "s": "0x53e15f0806b30399d63890783880f61bad387c6040afd231a044f047ca025b4d",
    "standardV": "0x0",
    "to": "0x642339c00133e27e6021968dd9e8304f9fab7348",
    "transactionIndex": null,
    "v": "0x4669",
    "value": "0x0"
  },
  "id": 1
}

The same code/procedure works correctly on Kovan network.

[jam10o-new]

It seems like future transactions are getting stuck behind some unconfirmed transaction, I'm hoping #10051 will be a fix for this but I'm not sure.

@seunlanlege @tomusdrw do you think this might be related?

[tomusdrw]

@jcortejoso how did you obtain "nonce": "0x48", for this transaction? Is it based on eth_getTransactionCount(<sender>) or parity_nextNonce(<sender>)?

[jcortejoso]

Hi @tomusdrw. We have solved the issue.
We were trying a custom POA Bridge and the nonce value was not taken correctly because of previous transactions between different networks. Testing with a clean environment works perfectly!

Thanks and sorry about the noise.