Fixing replacing transaction with lower gas_price result.

[tomusdrw]

1. Transaction tx=(sender1, nonce, gas_price) in future.
2. Importing transaction tx2=(sender1, nonce, gas_price+k) to current (state nonce changed in the meantime)
3. tx2 should be imported to current (and it was) but error was returned (which was incorrect)

[GitCop]

There were the following issues with your Pull Request

• Commit: 0ada865
  • Your subject line is longer than 72 characters

Guidelines are available at https://github.com/ethcore/parity

---

This message was auto-generated by https://gitcop.com

[GitCop]

There were the following issues with your Pull Request

• Commit: 0ada865
  • Your subject line is longer than 72 characters

Guidelines are available at https://github.com/ethcore/parity

---

This message was auto-generated by https://gitcop.com

[GitCop]

There were the following issues with your Pull Request

• Commit: 0ada865
  • Your subject line is longer than 72 characters

Guidelines are available at https://github.com/ethcore/parity

---

This message was auto-generated by https://gitcop.com

[gavofyork]

why would (sender1, nonce, price) be in the future yet (sender1, nonce, price+k) be in current? it's only the price which is different, which shouldn't affect current/future, right?

[tomusdrw]

This should never happen if we assume that queue is always notified by state changes (which should actually be the case right know through remove_all method).

The case described here assumes that (sender1, nonce, price) is inserted when state_nonce < nonce (hence going to future) and after that we try to import (sender1, nonce, price+k) but state_nonce == nonce and queue hasn't been notified about that.

[gavofyork]

the possibility that it can happen seems like a major bug in itself, no?

[tomusdrw]

Hmm, It might actually happen when you send transactions locally and manage nonce on your own, but it's imho highly improbable.

[gavofyork]

it should be impossible.

can you outline when the transactionqueue would get into such a state?

[tomusdrw]

1. state_nonce=n-1, queue lock to import using RPC, importing (sender1, nonce=n, gas_price) -> Goes to future
2. Acquire queue lock to import using RPC
3. New block is coming, state_nonce=n, transaction queue is not notified (cause lock is acquired by RPC)
4. importing throught RPC (sender1, nonce=n gas_price), state_nonce=n -> Goes to current

[gavofyork]

this could be fixed by having transaction queue notified of nonce-changes after block imports, right?

[gavofyork]

because 3 is a really big problem - it's very important future transactions get into current when the nonce changes.

[tomusdrw]

Transaction queue is notified about that, but because we have separate locks for transaction queue and state (client) described situation may happen - i.e. lock for queue can be held (in RPC), and in the meantime state is updated, but transaction queue is not yet notified because we're waiting for lock (in client).

[gavofyork]

ahh so s/is not notified/is not yet notified/