cad38415b2
* network: fix bug in inventory advertisement handling The RFC https://zebra.zfnd.org/dev/rfcs/0003-inventory-tracking.html described the use of a `broadcast` channel in place of an `mpsc` channel to get ring-buffer behavior, keeping a bound on the size of the channel but dropping old entries when the channel is full. However, it didn't explicitly describe how this works (the `broadcast` channel returns a `RecvError::Lagged(u64)` to inform receivers that they lost messages), so the lag-handling wasn't implemented and I didn't notice in review. Instead, the ? operator bubbled the lag error all the way up from `InventoryRegistry::poll_inventory` through `<PeerSet as Service>::poll_ready` through various Tower wrappers to users of the peer set. The error propagation is bad enough, because it caused client errors that shouldn't have happened, but there's a worse interaction. The `Service` contract distinguishes between request errors (from `Service::call`, scoped to the request) and service errors (from `Service::poll_ready`, scoped to the service). The `Service` contract specifies that once a service returns an error from `poll_ready`, the service can be assumed to be failed permanently. I believe (but haven't tested or carefully worked through the details) that this caused various tower middleware to report the entire peer set service as permanently failed due to a transient inventory "error" (more of an indicator), and I suspect that this is the cause of #1003, where all of the sync component's requests end up failing because the peer set reported that it failed permanently. I am able to reproduce #1003 locally before this change and unable to reproduce it locally after this change, though I have not tested exhaustively. * network: add metric for dropped inventory advertisements Co-authored-by: teor <teor@riseup.net> Co-authored-by: teor <teor@riseup.net> |
||
|---|---|---|
| .github | ||
| book | ||
| design | ||
| tower-batch | ||
| tower-fallback | ||
| zebra-chain | ||
| zebra-client | ||
| zebra-consensus | ||
| zebra-network | ||
| zebra-rpc | ||
| zebra-script | ||
| zebra-state | ||
| zebra-test | ||
| zebra-utils | ||
| zebrad | ||
| .firebaserc | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Dockerfile | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| clippy.toml | ||
| cloudbuild.yaml | ||
| codecov.yml | ||
| firebase.json | ||
| katex-header.html | ||
| prometheus.yaml | ||
README.md
Hello! I am Zebra, an ongoing Rust implementation of a Zcash node.
Zebra is a work in progress. It is developed as a collection of zebra-*
libraries implementing the different components of a Zcash node (networking,
chain structures, consensus rules, etc), and a zebrad binary which uses them.
Most of our work so far has gone into zebra-network, building a new
networking stack for Zcash, zebra-chain, building foundational data
structures, zebra-consensus, implementing consensus rules, and
zebra-state, providing chain state.
Rendered docs from the main branch.
License
Zebra is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT.