* p2p: add a per-message type send and receive metric (#9622)
* p2p: ressurrect the p2p envelope and use to calculate message metric
Add new SendEnvelope, TrySendEnvelope, BroadcastEnvelope, and ReceiveEnvelope methods in the p2p package to work with the new envelope type.
Care was taken to ensure this was performed in a non-breaking manner.
Co-authored-by: William Banfield <4561443+williambanfield@users.noreply.github.com>
Co-authored-by: William Banfield <wbanfield@gmail.com>
* Ignore generated/copied RPC docs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync vuepress config with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs package-lock.json with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs redirects with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs versions with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update OpenAPI version to v0.34
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync DOCS_README with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all v0.34.x docs references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update v0.34 OpenAPI references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo doc links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update code comment references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo root doc links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo root doc links for docs.tendermint.com from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Build v0.34.x as "latest"
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Explicitly mark v0.34 docs as latest in version selector
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add nav link to main and clearly mark as unstable
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Direct all docs.tendermint.com links to v0.34 on v0.34.x
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all relevant links on v0.34.x branch to be v0.34-specific
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update changelog refs to docs.tendermint.com
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update remaining GH master link to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs build and nav config with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Migrate spec links to GitHub repo from docs site
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Executed a local network using simapp and looked for logs that seemed superfluous. This isn't by any means an exhaustive grooming, but should drastically help legibility of logs.
ref: #5912
Conflicting votes are now sent to the evidence pool to form duplicate vote evidence only once
the height of the evidence is finished and the time of the block finalised.
blockchain/vX reactor priority was decreased because during the normal operation
(i.e. when the node is not fast syncing) blockchain priority can't be
the same as consensus reactor priority. Otherwise, it's theoretically possible to
slow down consensus by constantly requesting blocks from the node.
NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when
the node is fast syncing, the priority is 10 (max), but when it's done
fast syncing - the priority gets decreased to 5 (only to serve blocks
for other nodes). But it's not possible now, therefore I decided to
focus on the normal operation (priority = 5).
evidence and consensus critical messages are more important than
the mempool ones, hence priorities are bumped by 1 (from 5 to 6).
statesync reactor priority was changed from 1 to 5 to be the same as
blockchain/vX priority.
Refs https://github.com/tendermint/tendermint/issues/5816
After a reactor has failed to parse an incoming message, it shouldn't output the "bad" data into the logs, as that data is unfiltered and could have anything in it. (We also don't think this information is helpful to have in the logs anyways.)
