mirror of
https://github.com/tendermint/tendermint.git
synced 2026-01-07 13:55:17 +00:00
431618cef6
We first introduced auto-update as a separate struct AutoClient, which
was wrapping Client and calling Update periodically.
// AutoClient can auto update itself by fetching headers every N seconds.
type AutoClient struct {
base *Client
updatePeriod time.Duration
quit chan struct{}
trustedHeaders chan *types.SignedHeader
errs chan error
}
// NewAutoClient creates a new client and starts a polling goroutine.
func NewAutoClient(base *Client, updatePeriod time.Duration) *AutoClient {
c := &AutoClient{
base: base,
updatePeriod: updatePeriod,
quit: make(chan struct{}),
trustedHeaders: make(chan *types.SignedHeader),
errs: make(chan error),
}
go c.autoUpdate()
return c
}
// TrustedHeaders returns a channel onto which new trusted headers are posted.
func (c *AutoClient) TrustedHeaders() <-chan *types.SignedHeader {
return c.trustedHeaders
}
// Err returns a channel onto which errors are posted.
func (c *AutoClient) Errs() <-chan error {
return c.errs
}
// Stop stops the client.
func (c *AutoClient) Stop() {
close(c.quit)
}
func (c *AutoClient) autoUpdate() {
ticker := time.NewTicker(c.updatePeriod)
defer ticker.Stop()
for {
select {
case <-ticker.C:
lastTrustedHeight, err := c.base.LastTrustedHeight()
if err != nil {
c.errs <- err
continue
}
if lastTrustedHeight == -1 {
// no headers yet => wait
continue
}
newTrustedHeader, err := c.base.Update(time.Now())
if err != nil {
c.errs <- err
continue
}
if newTrustedHeader != nil {
c.trustedHeaders <- newTrustedHeader
}
case <-c.quit:
return
}
}
}
Later we merged it into the Client itself with the assumption that most clients will want it.
But now I am not sure. Neither IBC nor cosmos/relayer are using it. It increases complexity (Start/Stop methods).
That said, I think it makes sense to remove it until we see a need for it (until we better understand usage behavior). We can always introduce it later 😅. Maybe in the form of AutoClient.
order, parent
| order | parent | ||
|---|---|---|---|
| 1 |
|
Architecture Decision Records (ADR)
This is a location to record all high-level architecture decisions in the tendermint project.
You can read more about the ADR concept in this blog post.
An ADR should provide:
- Context on the relevant goals and the current state
- Proposed changes to achieve the goals
- Summary of pros and cons
- References
- Changelog
Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The spec is much more compressed and streamlined summary of everything as it stands today.
If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
Note the context/background should be written in the present tense.
Table of Contents:
- ADR-001-Logging
- ADR-002-Event-Subscription
- ADR-003-ABCI-APP-RPC
- ADR-004-Historical-Validators
- ADR-005-Consensus-Params
- ADR-006-Trust-Metric
- ADR-007-Trust-Metric-Usage
- ADR-008-Priv-Validator
- ADR-009-ABCI-Design
- ADR-010-Crypto-Changes
- ADR-011-Monitoring
- ADR-012-Peer-Transport
- ADR-013-Symmetric-Crypto
- ADR-014-Secp-Malleability
- ADR-015-Crypto-Encoding
- ADR-016-Protocol-Versions
- ADR-017-Chain-Versions
- ADR-018-ABCI-Validators
- ADR-019-Multisigs
- ADR-020-Block-Size
- ADR-021-ABCI-Events
- ADR-022-ABCI-Errors
- ADR-023-ABCI-Propose-tx
- ADR-024-Sign-Bytes
- ADR-025-Commit
- ADR-026-General-Merkle-Proof
- ADR-029-Check-Tx-Consensus
- ADR-030-Consensus-Refactor
- ADR-033-Pubsub
- ADR-034-Priv-Validator-File-Structure
- ADR-035-Documentation
- ADR-037-Deliver-Block
- ADR-039-Peer-Behaviour
- ADR-041-Proposer-Selection-via-ABCI
- ADR-043-Blockchain-RiRi-Org
- ADR-044-Lite-Client-With-Weak-Subjectivity
- ADR-045-ABCI-Evidence
- ADR-046-Light-Client-Implementation
- ADR-047-Handling-Evidence-From-Light-Client
- ADR-051-Double-Signing-Risk-Reduction
- ADR-052-Tendermint-Mode