closes: #8182
This pull request adds documentation to the `UPGRADING.md` file as well as a set of deprecation checks for the old timeout parameters in the `config.toml` file. It additionally documents the parameters in the `genesis.md`.
closes: #7756
# What does this pull request change?
This pull request adds a new runbook for operators enountering errors related to the new Proposer-Based Timestamps algorithm. The goal of this runbook is to give operators a set of clear steps that they can follow if they are having issues producing blocks because of clock synchronization problems.
This pull request also renames the `*PrevoteDelay` metrics to drop the term `MessageDelay`. These metrics provide a combined view of `message_delay` + `synchrony` so the name may be confusing.
# Questions to reviewers
* Are there ways to make the set of steps clearer or are there any pieces that seem confusing?
Fixes#8052 again. Ideally we would have some way of detecting that this
happens before merging, but the way we build docs right now is kind of
complicated.
This change set implements the most recent version of `FinalizeBlock`.
# What does this change actually contain?
* This change set is rather large but fear not! The majority of the files touched and changes are renaming `ResponseDeliverTx` to `ExecTxResult`. This should be a pretty inoffensive change since they're effectively the same type but with a different name.
* The `execBlockOnProxyApp` was totally removed since it served as just a wrapper around the logic that is now mostly encapsulated within `FinalizeBlock`
* The `updateState` helper function has been made a public method on `State`. It was being exposed as a shim through the testing infrastructure, so this seemed innocuous.
* Tests already existed to ensure that the application received the `ByzantineValidators` and the `ValidatorUpdates`, but one was fixed up to ensure that `LastCommitInfo` was being sent across.
* Tests were removed from the `psql` indexer that seemed to search for an event in the indexer that was not being created.
# Questions for reviewers
* We store this [ABCIResponses](5721a13ab1/proto/tendermint/state/types.pb.go (L37)) type in the data base as the block results. This type has changed since v0.35 to contain the `FinalizeBlock` response. I'm wondering if we need to do any shimming to keep the old data retrieveable?
* Similarly, this change is exposed via the RPC through [ResultBlockResults](5721a13ab1/rpc/coretypes/responses.go (L69)) changing. Should we somehow shim or notify for this change?
closes: #7658
This change adds an overview of the proposer-based timestamps algorithm. The goal of this documentation is to give a plain enough explanation of the algorithm so that application developers and validators can understand both the utility of the algorithm and understand how the new constrains may affect their network and topology.
I'm blanking on the scheme we decided on for docs linking, so if anyone could remind me what link format we decided on, I'll go clean that up ASAP.
Once this is merged, I intend to create a runbook for chains that see slower block-times or higher nil prevotes and link that runbook to this document to provide a higher-level overview.
closes: #8046
Since the goal of reading events at the head of the event log is to satisfy a
subscription style interface, there is no point in allowing head polling with
no wait interval. The pagination case already bypasses long polling, so the
extra option is unneessary.
Set a minimum default long-polling interval for the head case.
Add a test for minimum delay.
* Update ADR template
The reason for this proposed update to the ADR template is twofold:
1. There's currently no easy way to cross-reference between ADRs and
issues/PRs on GitHub. This may be easy to manage for those with
context while they're working on implementing an ADR, but after time
passes and for complex ADRs it gets more difficult for newcomers to
the codebase to track both the implementation status of the ADR or
its historical context and discussions.
2. We should not allow for "proposed" ADRs. An ADR is a **decision
record**, which implies acceptance, and not a proposal. RFCs provide
a mechanism to make proposals.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add example of one ADR superseding another
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Move "Proposed" ToC entries to "Accepted".
It's possible some of these should actually be "Implemented", but I did not try
to go through each one to distinguish.
* Revert "Move "Proposed" ToC entries to "Accepted"."
This reverts commit d8d2907e98.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Fix Markdown formatting
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add "Deprecated" section to ADR TOC
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Expand ADR template to explicitly cater for rejected ADRs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
Found by the link checker.
There are still some links that aren't fixed, because it's not clear where they _should_ point. I just hit the obvious ones.
There are a lot of existing links to the master section of the site, and my
attempts to get a redirector working have so far not succeeded. While it still
makes sense to not publish docs for unreleased code, a 404 is almost certainly
more disruptive than seeing docs for unreleased stuff.
This includes the docs in the build again, but does not add them back to the
selector menu. That allows URLs to resolve but encourages folks to use the
released versions when they have a choice.
I left the redirect for the RPC link in place, since that's still useful.
Updates #7935.
