This is meant as a supporting recruiting document. The idea is to
describe a bunch of projects scoped and selected as teaching projects
for new engineers joining the team.
This isn't meant to replace "neweng" or "good-first-ticket" tags on
issues, but provide a higher level set of examples of the kinds of
things that someone joining the team could tackle.
Update the static documentation about event subscription to include the new
/events API, and to add more details about how queries work. Mention that the
streaming API is deprecated.
This pull request adds an additional set of metrics targeted at providing more visibility into `abci++`.
The following set of metrics are added and exposed through the `metrics` endpoint:
```
tendermint_consensus_proposal_receive_count{chain_id="test-chain-IrF74Y",status="accepted"} 34
tendermint_consensus_proposal_create_count{chain_id="test-chain-IrF74Y"} 34
tendermint_consensus_vote_extension_receive_count{chain_id="test-chain-IrF74Y",status="accepted"} 34
tendermint_consensus_round_voting_power_percent{chain_id="test-chain-IrF74Y",vote_type="precommit"} 1
tendermint_consensus_round_voting_power_percent{chain_id="test-chain-IrF74Y",vote_type="prevote"} 1
tendermint_state_consensus_param_updates{chain_id="test-chain-IrF74Y"} 0
tendermint_state_validator_set_updates{chain_id="test-chain-IrF74Y"} 0
tendermint_consensus_late_votes{chain_id="test-chain-IrF74Y",vote_type="precommit"} 16
```
This pull request also updates the `metrics.md` file to include some metrics that were previously missed. My hope is to generate the `metrics.md` file with a future version of the tool being architected in #8479
Per https://github.com/tendermint/docs/issues/20, it is no longer necessary to
build the static documentation out of a separate repository.
This change:
- Adds an actions workflow to build and deploy the docs to GitHub Pages.
- Updates some build settings in a compatible manner.
This change does not affect the existing site deployment. To complete this
change, we will need to update the custom domain pointer and disable the
corresponding workflow in the tendermint/docs repository. Those changes can and
must be done after this is merged.
In the future should probably also move the build rule out of the Makefile and
into the workflow directly. That will also make it easier to manage caching of
build artifacts. For now, however, I've left it as-is, so that we do not break
the active workflow on tendermint/docs, which depends on it.
This RFC discusses issues in how we migrate configuration data across
Tendermint versions, and some options for how to improve the experience for
node operators in the future.
This script verifies that each document in the docs and architecture directory
has a corresponding table-of-contents entry in its README file. It can be run
manually from the command line.
- Hook up this script to run in CI (optional workflow).
- Update ADR ToC to include missing entries this script found.
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.
