Tendermint version : 0.26.4-b771798d
ABCI app : kv-store
Environment:
- OS (e.g. from /etc/os-release): macOS 10.14.1
What happened:
Set mempool.recheck = false and create empty block = false in config.toml.
When transactions get added right between a new empty block is being proposed and committed,
the proposer won't propose new block for that transactions immediately after.
That transactions are stuck in the mempool until a new transaction is added and trigger the proposer.
What you expected to happen:
If there is a transaction left in the mempool, new block should be proposed immediately.
Have you tried the latest version: yes
How to reproduce it (as minimally and precisely as possible):
Fire two transaction using broadcast_tx_sync with specific delay between them.
(You may need to do it multiple time before the right delay is found, on my machine the delay is 0.98s)
Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file): https://pastebin.com/0Wt6uhPF
Config (you can paste only the changes you've made):
[mempool]
recheck = false
create_empty_block = false
Anything else we need to know:
In mempool.go, we found that proposer will immediately propose new block if
- Last committed block has some transaction (causing AppHash to changed) or
mem.notifyTxsAvailable() is called.
Our scenario is as followed.
- A transaction is fired, it will create 1 block with 1 tx (line 1-4 in the log) and 1 empty block.
- After the empty block is proposed but before it is committed, second transaction is fired and added to mempool. (line 8-16)
Now, since the last committed block is empty and mem.notifyTxsAvailable() will be called only if mempool.recheck = true.
The proposer won't immediately propose new block, causing the second transaction to stuck in mempool until another transaction is added to mempool and trigger mem.notifyTxsAvailable().
Tendermint version : 0.26.4-b771798d
ABCI app : kv-store
Environment:
What happened:
Set
mempool.recheck = falseandcreate empty block = falseinconfig.toml.When transactions get added right between a new empty block is being proposed and committed,
the proposer won't propose new block for that transactions immediately after.
That transactions are stuck in the mempool until a new transaction is added and trigger the proposer.
What you expected to happen:
If there is a transaction left in the mempool, new block should be proposed immediately.
Have you tried the latest version: yes
How to reproduce it (as minimally and precisely as possible):
Fire two transaction using
broadcast_tx_syncwith specific delay between them.(You may need to do it multiple time before the right delay is found, on my machine the delay is 0.98s)
Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file): https://pastebin.com/0Wt6uhPF
Config (you can paste only the changes you've made):
[mempool]
recheck = false
create_empty_block = false
Anything else we need to know:
In
mempool.go, we found that proposer will immediately propose new block ifmem.notifyTxsAvailable()is called.Our scenario is as followed.
Now, since the last committed block is empty and
mem.notifyTxsAvailable()will be called only ifmempool.recheck = true.The proposer won't immediately propose new block, causing the second transaction to stuck in mempool until another transaction is added to mempool and trigger
mem.notifyTxsAvailable().