Before: scheduler receives psBlockProcessed event, but does not mark block as processed because peer timed out (or was removed for other reasons) and all associated blocks were rescheduled.
After: scheduler receives psBlockProcessed event and marks block as processed in any case (even if peer who provided this block errors).
Closes#5387
When a peer is stopped due to some network issue, the Reactor calls scheduler#handleRemovePeer, which removes the peer from the scheduler. BUT the peer stays in the processor, which sometimes could lead to "duplicate block enqueued by processor" panic WHEN the same block is requested by the scheduler again from a different peer. The solution is to return scPeerError, which will be propagated to the processor. The processor will clean up the blocks associated with the peer in purgePeer.
Closes#5513, #5517
Fixes#5439. This is really a workaround for #5519 (unless we require async implementations to return ordered responses, but that kind of defeats the purpose of having an async API).
* mempool: length prefix txs when getting them from mempool (#5483)
* correctly calculate evidence data size (#5482)
* block: use commit sig size instead of vote size (#5490)
* tx: reduce function to one parameter (#5493)
This change adds some polish to the upgrading instructions for 0.34. The only substantive changes include:
* Calling out ABCI-impacting changes explicitly in the "ABCI Changes" section, even if those changes are also mentioned elsewhere
* Removes `ProofOfTrialPeriod` from consensus params; this change was introduced and then removed.
found out this issue when trying to decouple mempool reactor with its
underlying clist implementation.
according to its comment, the test `TestReactorNoBroadcastToSender` is
intended to make sure that a peer shouldn't send tx back to its origin.
however, the current test forgot to init peer state key, thus the code
will get stuck at waiting for peer to catch up state *instead of* skipping
sending tx back:
b8d08b9ef4/mempool/reactor.go (L216-L226)
this PR fixes the issue by init peer state key.
Revert the JSON-RPC/WebSocket response serialization format to the
standard way (i.e. a single RPC response per WebSocket text message) to
avoid breaking clients.
Serialization format changes will be discussed in an upcoming ADR.
Closes: #5373
## Description
This PR adds support for badgerdb, rocksdb and boltdb within the build options.
RocksDB builds correctly.
```
make build TENDERMINT_BUILD_OPTIONS=rocksdb
CGO_ENABLED=1 go build -mod=readonly -ldflags "-X github.com/tendermint/tendermint/version.GitCommit=`git rev-parse --short=8 HEAD` -s -w " -trimpath -tags 'tendermint rocksdb' -o build/tendermint ./cmd/tendermint/
tendermint on master [$!] via 🐹 v1.15.2 took 19s
```
Closes: #5355
## Description
Add a sentence on `initial_height`.
There will be a section in the spec repo explaining the genesis more in depth as this is something that will affect both clients
Closes: #XXX
## Description
Check block protocol version in header validate basic.
I tried searching for where we check the P2P protocol version but was unable to find it. When we check compatibility with a node we check we both have the same block protocol and are on the same network, but we do not check if we are on the same P2P protocol. It makes sense if there is a handshake change because we would not be able to establish a secure connection, but a p2p protocol version bump may be because of a p2p message change, which would go unnoticed until that message is sent over the wire. Is this purposeful?
Closes: #4790
Callum Waters
Erik Grinaker
Anton Kaliaev
Marko
Tess Rinearson
dependabot[bot]
ninjaahhh
Thane Thomson
