zecfoundation
/
zebra
mirror of https://github.com/ZcashFoundation/zebra.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zebra/Cargo.toml

25 lines
461 B
TOML
Raw Normal View History

Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
[workspace]
members = [
reorder workspace crates (#651)
2020-07-14 13:23:43 -07:00
"zebrad",
Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
"zebra-chain",
"zebra-network",
Add initial version of zebra-state (#414) * rename zebra-storage to zebra-state * Setup initial skeleton for zebra-state * add test * Apply suggestions from code review Co-authored-by: Henry de Valence <hdevalence@hdevalence.ca> * move shared test vectors to a common crate Co-authored-by: Jane Lusby <jane@zfnd.org> Co-authored-by: Henry de Valence <hdevalence@hdevalence.ca>
2020-06-02 16:16:17 -07:00
"zebra-state",
Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
"zebra-script",
"zebra-consensus",
"zebra-rpc",
"zebra-client",
rename zebra-test-vectors to zebra-test
2020-06-22 19:34:11 -07:00
"zebra-test",
setup skeleton zebra-utils crate for independent binaries (#638) * setup skeleton zebra-utils crate for independent binaries * resolve review comments
2020-07-10 12:31:01 -07:00
"zebra-utils",
reorder workspace crates (#651)
2020-07-14 13:23:43 -07:00
"tower-batch",
tower-fallback: add implementation.
2020-07-14 16:21:01 -07:00
"tower-fallback",
Remove zebra-reactor. This functionality will just go in zebrad and use abscissa, allowing configs, component registries, etc. Closes #59
2019-10-10 15:43:54 -07:00
]
fix panic in seed subcommand (#401) Co-authored-by: Jane Lusby <jane@zfnd.org> Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs. First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections. The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
[profile.dev]
panic = "abort"
[profile.release]
fix tracing configuration issues (#432)
2020-06-04 19:34:06 -07:00
panic = "abort"
deps: use Tower 0.4 from git instead of 0.3.1. This addresses at least three pain points: - we were affected by bugs that were already fixed in git, but not in the released crate; - we can use service combinators to transform requests and responses; - we can use the hedge middleware. The version in git is still marked as 0.3.1 but these changes will be part of tower 0.4: https://github.com/tower-rs/tower/issues/431
2020-09-21 14:00:20 -07:00
[patch.crates-io]
zebrad: use hedged requests in sync The hedge middleware implements hedged requests, as described in _The Tail At Scale_. The idea is that we auto-tune our retry logic according to the actual network conditions, pre-emptively retrying requests that exceed some latency percentile. This would hopefully solve the problem where our timeouts are too long on mainnet and too slow on testnet.
2020-09-22 10:46:50 -07:00
tower = { git = "https://github.com/tower-rs/tower", rev = "1a84543" }