A bunch of lints to catch common mistakes and improve your Rust code
tokio-rs/tracing 1026
Application level tracing for Rust.
RustBeginners/awesome-rust-mentors 366
A list of rust lang mentors tagged by topics of interest
🍄
Crate for the quick creation of anonymous error types from strings
Proposal on how deno doctest will work, inspired by rustdoc --test
A minimal deserialization library for std::backtrace::Backtrace's debug format
hdevalence/tcn-backend-simulator 1
experimental in-memory TCN protocol backend and simulator
push eventZcashFoundation/zebra
commit sha 7d4bdba7b03a2da7d6562970be6e46c7799185ec
revert unnecessary change in sync_until
push time in 10 hours
push eventZcashFoundation/zebra
commit sha b9dec28be9f917b83a78c0c0ac0caadb6002a9aa
further make use statement consistent
push time in 10 hours
push eventZcashFoundation/zebra
commit sha 30e308a299ccc0f9de539c4c82aefe892d87b6db
fix use cfg
push time in 10 hours
push eventZcashFoundation/zebra
commit sha a18d1555d1abf4fed4de5409d8fb4a06851ca2c8
update acceptance tests
push time in 10 hours
issue commentyaahc/eyre
Something like `ContextCompat` but for options only
Would you consider adding something like
OptionContextwhich would add.contextfor options only?
I think it should be possible to write this trait impl outside of color-eyre, so I lean towards not adding it since it seems like a style preference rather than something I'd want to encourage generally. My preference is to use ok_or for converting options to errors, and I feel adding an OptionContext would encourage ppl away from a common style.
I've just noticed ContextCompat lets me use even .wrap_err on options instead of .context, why?
I don't think there was a reason, if I had thought about it at the time leaving out wrap_err seems like a good choice, but now it's a breaking change :(
comment created time in 16 hours
Pull request review commentZcashFoundation/zebra
Implement Expanded to Compact Difficulty Conversion
fn equihash_prop_test_input() -> color_eyre::eyre::Result<()> { Ok(()) }++proptest! {+ /// Check Expanded, Compact, Work, and PartialCumulativeWork conversions.+ ///+ /// Make sure the conversions don't panic, and that they round-trip and compare+ /// correctly.+ #[test]+ fn prop_difficulty_conversion(expanded_seed in any::<block::Hash>()) {+ let expanded_seed = ExpandedDifficulty::from_hash(&expanded_seed);++ let hash_zero = block::Hash([0; 32]);+ let hash_max = block::Hash([0xff; 32]);+ prop_assert!(expanded_seed >= hash_zero);+ prop_assert!(expanded_seed <= hash_max);++ // Skip invalid seeds+ prop_assume!(expanded_seed != hash_zero);++ let compact = expanded_seed.to_compact();+ let expanded_trunc = compact.to_expanded();+ let work = compact.to_work();++ let work_zero = Work(0);+ let work_max = Work(u128::MAX);++ if let Some(expanded_trunc) = expanded_trunc {
sounds like its good, I'd have just put some tracing events into each of the branches to ensure that they were emitting output, but I think if it passes with multiple iterations and minimal rejects allowed, which afaik counter filtered out inputs, then I think we're good.
comment created time in 16 hours
Pull request review commentZcashFoundation/zebra
Implement Expanded to Compact Difficulty Conversion
impl Arbitrary for equihash::Solution { type Strategy = BoxedStrategy<Self>; }++impl Arbitrary for CompactDifficulty {+ type Parameters = ();++ fn arbitrary_with(_args: Self::Parameters) -> Self::Strategy {+ (vec(any::<u8>(), 32))+ .prop_filter_map("zero CompactDifficulty values are invalid", |v| {
sounds good
comment created time in 16 hours
pull request commentZcashFoundation/zebra
Add network integration test for quick post sapling sync testing
These currently timeout
thats to be expected, this was just me trying to set something up that would download the chain, but that takes like 8 hours so its definitely not gonna work from within a github actions job without the cached data
comment created time in a day
push eventZcashFoundation/zebra
commit sha 518ae6b2e5d44560ca72177f88bf0e8b8da61d29
Update .github/pull_request_template.md Co-authored-by: teor <[email protected]>
push time in 2 days
Pull request review commentZcashFoundation/zebra
Add review guidelines to the default PR template
Summarize the solution and provide any necessary context needed to understand the code change. --> +## Follow Up Work++<!--+Is there anything missing from the solution?+What still needs to be done?+-->+ ## Related Issues <!-- Please link to any existing GitHub issues pertaining to this PR. -->++## Review Guidelines (for Reviewer)+<!--+This is a flexible checklist for the reviewer to fill in.++Developers:+Add extra tasks to the review using list items.+Skip review tasks using ~~strikethrough~~, or just delete them.+If you want this pull request to have a specific reviewer, tag them in the list of reviewers.++Reviewer:+This checklist can help you do your review.+Add or skip tasks as needed.+-->++**Does this pull request improve Zebra?**
:+1:
comment created time in 2 days
pull request commentZcashFoundation/zebra
WIP: Add all necessary sled trees to zebra-state as defined in RFC0005
Will we merge this PR, and switch to v2 when we can compute anchors? Or will we wait until we can compute anchors, finish this PR, and stay on v1?
I think we should do the former
comment created time in 2 days
PR opened ZcashFoundation/zebra
Motivation
This change implements the second of three tests described in the basic network integration testing RFC. This test is meant to act as a quick test of sync behavior immediately post checkpointing.
<!-- Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of as being the motivation for your change. -->
Solution
This test is implemented by persisting a copy of the database that has been synced to sapling checkpoint height. This starting point is then used to sync the next few thousand blocks immediately after the Sapling activation.
<!-- Summarize the solution and provide any necessary context needed to understand the code change. -->
Related Issues
- https://github.com/ZcashFoundation/zebra/pull/1007 <!-- Please link to any existing GitHub issues pertaining to this PR. -->
Unresolved Questions
This design is currently an incomplete sketch of just the initial pieces of the final integration test. Syncing to a certain point and backing up the database, and starting from the backup if one already exists. This doesn't help us on our CI as it is currently implemented. Github Actions and Google Cloud Build both have little to no support for persistent data on test runners. We would have to copy the entire database over the network before each test run. There are a couple of solutions that I'm currently investigating:
VM + Custom Job Queue
Setup a persistent VM used to run these tests and some basic CI infra that can be used to dispatch and queue test jobs to that VM. That VM would then own the persisted copy of the up-to-sapling database. Test jobs would be sent from github actions and/or google cloud build, which would tell the remote VM to download the pre compiled zebrad image and run the test. Once the test completes it would reply back to the runner that requested the job, passing it the test results and letting its process exit.
Custom FUSE
Alternatively, we might be able to setup a simple FUSE that we can then mount in our Github Actions or Google Cloud Build containers. The FUSE would be only implement the minimum API needed to represent the single database file used by sled. It would implement copy on write functionality, where if sled tries to read a block that hasn't been updated locally it will read that block from the database file over the network, and if sled tries to write to an existing block or write a new one it would store the new block data in memory or on another file locally, rather than writing that data back to the database file on the network.
pr created time in 2 days
push eventtokio-rs/tracing
commit sha 19af2924f1bcf9c458264a420adc5b77ae17e93e
chore: fix tracing-macros::dbg (#1054) …and the `factorial` example.
commit sha 499d3da19c4b36008bcfd934fa0ff3224921f909
chore(deps): update env_logger requirement from 0.7 to 0.8 (#1050) Updates the requirements on [env_logger](https://github.com/env-logger-rs/env_logger) to permit the latest version. - [Release notes](https://github.com/env-logger-rs/env_logger/releases) - [Changelog](https://github.com/env-logger-rs/env_logger/blob/master/CHANGELOG.md) - [Commits](https://github.com/env-logger-rs/env_logger/compare/v0.7.0...v0.8.1) Signed-off-by: dependabot-preview[bot] <[email protected]> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
commit sha 67340e911f8362209940836741b38c9295a3d040
subscriber: make Registry::enter/exit much faster (#1058) ## Motivation We've tried very hard to make sure that entering and exiting spans is lightweight...in the `tracing-core` core machinery. Unfortunately, we haven't done any benchmarking of how subscriber implementations actually handle enter/exit events. It turns out that in `tracing-subscriber`'s `Registry`, there's actually significant overhead for entering a span: calling `span.enter()` may take as long as 69 ns (on my machine). ## Solution I've written some microbenchmarks for entering and exiting enabled spans using `tracing-subscriber::fmt`, comparing them with the overhead of calling `enter` on an enabled span. Based on this, I've made some performance improvements. These optimizations include: - Removing the `HashSet` that's used for tracking previously entered span IDs, in favor of linear search. Span stacks probably never deep enough for a hashmap to be faster than iterating over a couple of vec indices. - Preallocating the vec used for the span stack to hold at least 64 elements. This means we'll never have a lag spike from reallocating, as I think it'll almost never be deeper than 64 IDs. - Only cloning/dropping an ID's ref count for the _first_ ID in the stack. This makes entering and exiting enabled spans significantly faster:  It would be nice to continue optimizing this, but this might be about the best it gets given the other requirements that we're now making assertions about. Signed-off-by: Eliza Weisman <[email protected]>
commit sha 0dc8ef2da97f605689fff17f6c38b69e105a5281
subscriber: remove TraceLogger (#1052) * Remove TraceLogger The `TraceLogger` implementation is deprecated and this PR removes it completely.
commit sha b7b14df21943480c2a425f0510634cf9e5ce61b1
chore: fix rustdoc warning in tracing-subscriber (#1061)
commit sha 98ba44c22ee0d5f96f464b2d0fea8d577c69be7f
core: rename Subscriber to Collect (#1015) This PR renames the following: - `tracing_core::Subscriber` to `tracing_core::Collect` - `tracing_subscriber::layer::Layer` to `tracing_subscriber::layer::Subscribe` Authored-by: David Barsksy <[email protected]> Co-authored-by: Eliza Weisman <[email protected]>
commit sha eeb6974cab7277d5691fee91df8947fe71e05151
subscriber: remove deprecated type, structs, and methods #1030 This PR removes the deprecated items in `tracing-subscriber`. It _does not_ remove `Collect::drop_span` as that will happen in a separate PR. Note that branch builds atop of #1015, which means: - #1015 needs to be merged first - This PR will be rebased against the master branch containing #1015. - _Then_ this can safely be merged.
commit sha 1bf9da2bc7fee836bbb85051d42570ed8b7c5731
subscriber: update sharded-slab to 0.1, pool hashmap allocations (#1062) ## Motivation hawkw/sharded-slab#45 changes `sharded-slab` so that the per-shard metadata is allocated only when a new shard is created, rather than all up front when the slab is created. This fixes the very large amount of memory allocated by simply creating a new `Registry` without actually collecting any traces. ## Solution This branch updates `tracing-subscriber` to depend on `sharded-slab` 0.1.0, which includes the upstream fix. In addition, this branch the registry from using `sharded_slab::Slab` to `sharded_slab::Pool`. This allows us to clear hashmap allocations for extensions in-place, retaining the already allocated maps. This should improve `new_span` performance a bit. Fixes #1005
commit sha bd8c6da0ce7561fc2b6c1e6a5c993f7209e155b3
subscriber: add `Pretty` formatter (#1067) ## Motivation Currently, the `tracing_subscriber::fmt` module contains only single-line event formatters. Some users have requested a human-readable, pretty-printing event formatter optimized for aesthetics. ## Solution This branch adds a new `Pretty` formatter which uses an _excessively_ pretty output format. It's neither compact, single-line oriented, nor easily machine-readable, but it looks _quite_ nice, in my opinion. This is well suited for local development or potentially for user-facing logs in a CLI application. Additionally, I tried to improve the docs for the different formatters currently provided, including example output. Check out [the Netlify preview][1]! [1]: https://deploy-preview-1067--tracing-rs.netlify.app/tracing_subscriber/fmt/index.html#formatters Signed-off-by: Eliza Weisman <[email protected]>
commit sha 70d55afba04042c20bba97ce5b1ad15dda92cf09
subscriber: make `Compact` formatter not be useless (#1069) Depends on #1067 ## Motivation Currently, the `Compact` event formatter in `tracing-subscriber` is...kind of bad, and nobody seems to use it. It outputs the names of all the spans in the current context, and (inexplicably) the _names_ of all the fields on the current span, but not their values. This isn't very useful. ## Solution This branch rewrites the `Compact` formatter to be a little less bad. Now, we output all the fields from the current span context, but skip span names, and we shorten the level to a single character when it's enabled. Additionally, using the `compact` formatter disables targets by default. Now, the lines are nicely short, but maybe still useful. Example output before this change:  ...and after:  Signed-off-by: Eliza Weisman <[email protected]>
commit sha eadf2a23da21cc1e9572ed223fe386ef956e1afe
chore: Fix several renames missed in #1015 (#1066) The changes were in tests, tracing-error, and example.
commit sha 9b09d13399b87d55253943c180074d19e7701265
Merge branch 'master' into traced-error-map
push time in 2 days
push eventtokio-rs/tracing
commit sha b83cbbce9205a95940bd130a6f197fee13b38a3e
Apply suggestions from code review Co-authored-by: Eliza Weisman <[email protected]>
push time in 2 days
Pull request review commentZcashFoundation/zebra
(Some) semantic transaction verification checks
pub enum TransactionError { #[error("coinbase input found in non-coinbase transaction")] CoinbaseInputFound, + #[error("coinbase transaction MUST NOT have any JoinSplit descriptions or Spend descriptions")]+ CoinbaseHasJoinSplitOrSpend,+ #[error("coinbase transaction failed subsidy validation")] Subsidy(#[from] SubsidyError),++ #[error("transaction version number MUST be >= 4")]+ WrongVersion,++ #[error("at least one of tx_in_count, nShieldedSpend, and nJoinSplit MUST be nonzero")]+ NoTransfer,++ #[error("if there are no Spends or Outputs, the value balance MUST be 0.")]+ BadBalance,++ /// Could not verify a transparent script+ Script(#[from] zebra_script::Error),++ // XXX change this when we align groth16 verifier errors with bellman+ // and add a from annotation when the error type is more precise+ #[error("spend proof MUST be valid given a primary input formed from the other fields except spendAuthSig")]+ Groth16(BoxError),++ #[error(+ "joinSplitSig MUST represent a valid signature under joinSplitPubKey of dataToBeSigned"+ )]+ Ed25519(#[from] ed25519::Error),++ #[error("bindingSig MUST represent a valid signature under the transaction binding validating key bvk of SigHash")]+ RedJubjub(redjubjub::Error),+}++impl From<BoxError> for TransactionError {+ fn from(err: BoxError) -> Self {+ match err.downcast::<redjubjub::Error>() {+ Ok(e) => TransactionError::RedJubjub(*e),+ Err(e) => TransactionError::Internal(e),+ }+ } }
Sounds reasonable, lets go ahead and remove the Internal variant completely and just panic if we run into an error that we don't expect. I think the only other source of errors are errors introduced by tower, and if we end up running into those we can probably change this to a TryFrom impl and handle tower errors separately at the conversion site or figure it out once we encounter it.
comment created time in 2 days
pull request commentyaahc/color-eyre
I'm sorry for not replying to this for so long, life has been getting in the way. Just know that this is high on my list of priorities and I'll get to this as soon as I can.
comment created time in 2 days
issue closedtower-rs/tower
Add generic parameters to specify the error type of middleware that return their own error types
Right now tower provides ~5 service wrappers that introduce their own error variants in addition to the the errors returned by a wrapped service, e.g. Buffer. Currently they're setup so that each of these structs return a Box<dyn Error> which it can use to either return the inner error type or its own error type. This is ideal for convenient propagation of error types and API stability but has significant downsides when it comes to composition with other error handling types because Box<dyn Error> does not implement std::error::Error and Box<dyn Error> can only store types that implement std::error::Error.
Together these two restrictions make the given tower middleware incompatible with more feature rich error reporting types like anyhow::Error or eyre::Report. Because these reporting types implement From<E: Error> they can not implement From<Box<dyn Error>> or Error, because both implementations would violate the overlap rule. This means you cannot use error reporting types in services that are wrapped by tower middleware or convert the errors returned from the middleware into said error reporting types without significant amounts of boilerplate.
Instead of Box<dyn Error> these types should have a generic parameter added to them to specify the error type that will be used to unify the errors from the middleware and the inner service. This generic parameter could then be set to Box<dyn Error> which would opt into the current behaviour, it could be set to another error reporting type like eyre::Report letting the inner services construct more meaningful error reports and capture more context such as SpanTraces from within the inner service, or it could even be set to an enum type for users who wish to force explicit handling of all possible error variants.
This design has already been applied to tower-batch in zebra which is itself based on tower-buffer. Please refer to https://github.com/ZcashFoundation/zebra/pull/500 to see what changes were necessary. The key difference is that the new generic error type requires crate::BatchError: Into<E> and S::Error: Into<E>, instead of requiring Into<Box>.
cc @jonhoo @hawkw @LucioFranco
closed time in 2 days
yaahc
issue commenttower-rs/tower
Add generic parameters to specify the error type of middleware that return their own error types
I think we can go ahead and close this
comment created time in 2 days
pull request commenthttp-rs/http-types
In Tide all runtime errors stay within Tide - any that end up at the response are converted into a
500 Internal Server Error. To deal with runtime errors a logger middleware must be installed (one comes installed by default but can be disabled or replaced). It would have to handle the interaction with eyre reporting. Maybe you have some suggestions on how to best do that?
Probably, but I'll need more details:
to deal with runtime errors ...
Deal with how, just by logging or discarding them?
It would have to handle the interaction with eyre reporting
might also need clarification here, depending on the answer to the previous question.
comment created time in 2 days
pull request commenttokio-rs/tracing
Add support for converting errors wrapped by TracedError
I'm not sure why the CI failed, so I restarted it
comment created time in 2 days
push eventtokio-rs/tracing
commit sha b2e5e7d454c1e081d3332d764e870d7bf87b17fe
Add example for err_into
commit sha 00e8922dbfc1d6450676a0879038d2313ff60b01
Merge branch 'traced-error-map' of github.com:tokio-rs/tracing into traced-error-map
push time in 2 days
push eventtokio-rs/tracing
commit sha 375ba5df3b908b132009598ca1faf6206923d03d
Update tracing-error/src/error.rs Co-authored-by: Eliza Weisman <[email protected]>
push time in 2 days
push eventtokio-rs/tracing
commit sha 8c82fffa3eb5f410f7df9f87a90d9a528f068373
add a doc comment
push time in 2 days
Pull request review commenttokio-rs/tracing
Add support for converting errors wrapped by TracedError
where // error/display/debug impls to the internal error type from the type erased error type. // // The repr(C) is necessary to ensure that the struct is layed out in the order we- // specified it so that we can safely access the vtable and spantrace fields thru a type+ // specified it, so that we can safely access the vtable and spantrace fields through a type // erased pointer to the original object. let vtable = &ErrorVTable { object_ref: object_ref::<E>, }; - Self {+ TracedError { inner: ErrorImpl { vtable,- span_trace: SpanTrace::capture(),+ span_trace, error, }, } }++ /// Convert the inner error type of a `TracedError` while preserving the+ /// attached `SpanTrace`.+ ///+ /// # Examples+ ///+ /// ```rust+ /// use tracing_error::TracedError;+ /// # #[derive(Debug)]+ /// # struct InnerError;+ /// # #[derive(Debug)]+ /// # struct OuterError(InnerError);+ /// # impl std::fmt::Display for InnerError {+ /// # fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+ /// # write!(f, "Inner Error")+ /// # }+ /// # }+ /// # impl std::error::Error for InnerError {+ /// # }+ /// # impl std::fmt::Display for OuterError {+ /// # fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+ /// # write!(f, "Outer Error")+ /// # }+ /// # }+ /// # impl std::error::Error for OuterError {+ /// # fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {+ /// # Some(&self.0)+ /// # }+ /// # }+ ///+ /// let err: TracedError<InnerError> = InnerError.into();+ /// let err: TracedError<OuterError> = err.map(|inner| OuterError(inner));+ /// ```+ pub fn map<F, O>(self, op: O) -> TracedError<F>+ where+ O: FnOnce(E) -> F,+ F: std::error::Error + Send + Sync + 'static,+ {+ let span_trace = self.inner.span_trace;+ let error = self.inner.error;+ let error = op(error);++ TracedError::new(error, span_trace)+ }++ /// Convert the inner error type of a `TracedError` while preserving the+ /// attached `SpanTrace` using the inner error's `Into` impl.+ pub fn err_into<F>(self) -> TracedError<F>
I created an example and tested it out and it seems to work great, but I don't think there's much gained, and this at least avoids the issue and any potential confusion, so I think we should leave it as is.
comment created time in 2 days
push eventtokio-rs/tracing
commit sha fff00900d1965c1a7d0e55c86adc98c4fd6d7e96
Add example usage for map-traced-error
push time in 2 days
Pull request review commenttokio-rs/tracing
Add support for converting errors wrapped by TracedError
where // error/display/debug impls to the internal error type from the type erased error type. // // The repr(C) is necessary to ensure that the struct is layed out in the order we- // specified it so that we can safely access the vtable and spantrace fields thru a type+ // specified it, so that we can safely access the vtable and spantrace fields through a type // erased pointer to the original object. let vtable = &ErrorVTable { object_ref: object_ref::<E>, }; - Self {+ TracedError { inner: ErrorImpl { vtable,- span_trace: SpanTrace::capture(),+ span_trace, error, }, } }++ /// Convert the inner error type of a `TracedError` while preserving the+ /// attached `SpanTrace`.+ ///+ /// # Examples+ ///+ /// ```rust+ /// use tracing_error::TracedError;+ /// # #[derive(Debug)]+ /// # struct InnerError;+ /// # #[derive(Debug)]+ /// # struct OuterError(InnerError);+ /// # impl std::fmt::Display for InnerError {+ /// # fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+ /// # write!(f, "Inner Error")+ /// # }+ /// # }+ /// # impl std::error::Error for InnerError {+ /// # }+ /// # impl std::fmt::Display for OuterError {+ /// # fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+ /// # write!(f, "Outer Error")+ /// # }+ /// # }+ /// # impl std::error::Error for OuterError {+ /// # fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {+ /// # Some(&self.0)+ /// # }+ /// # }+ ///+ /// let err: TracedError<InnerError> = InnerError.into();+ /// let err: TracedError<OuterError> = err.map(|inner| OuterError(inner));+ /// ```+ pub fn map<F, O>(self, op: O) -> TracedError<F>+ where+ O: FnOnce(E) -> F,+ F: std::error::Error + Send + Sync + 'static,+ {+ let span_trace = self.inner.span_trace;+ let error = self.inner.error;+ let error = op(error);++ TracedError::new(error, span_trace)+ }++ /// Convert the inner error type of a `TracedError` while preserving the+ /// attached `SpanTrace` using the inner error's `Into` impl.+ pub fn err_into<F>(self) -> TracedError<F>
I'm wondering if we could just call this into, I think method resolution might work out in our favor here, I'm trying to think of scenarios where it could break...
comment created time in 2 days
push eventtokio-rs/tracing
commit sha 3b965aa335e674061dc109f2acf25410aa2671ab
add new fn and err_into
push time in 2 days
Pull request review commentZcashFoundation/zebra
Add review guidelines to the default PR template
Summarize the solution and provide any necessary context needed to understand the code change. --> +## Follow Up Work++<!--+Is there anything missing from the solution?+What still needs to be done?+-->+ ## Related Issues <!-- Please link to any existing GitHub issues pertaining to this PR. -->++## Review Guidelines (for Reviewer)+<!--+This is a flexible checklist for the reviewer to fill in.++Developers:+Add extra tasks to the review using list items.+Skip review tasks using ~~strikethrough~~, or just delete them.+If you want this pull request to have a specific reviewer, tag them in the list of reviewers.++Reviewer:+This checklist can help you do your review.+Add or skip tasks as needed.+-->++**Does this pull request improve Zebra?**
I think this still has those same unintentional connotation issues. How do you feel about this version?
- [ ] Description
- **Does this PR focus on and achieve a clearly defined goal.**
- The PR description highlights a concrete problem.
- The solution directly solves the stated problem, rather than circumvents it (as possible).
- The implemented code is not intended to be thrown away at a later date.
comment created time in 3 days
Pull request review commentZcashFoundation/zebra
Add review guidelines to the default PR template
Summarize the solution and provide any necessary context needed to understand the code change. --> +## Follow Up Work++<!--+Is there anything missing from the solution?+What still needs to be done?+-->+ ## Related Issues <!-- Please link to any existing GitHub issues pertaining to this PR. -->++## Review Guidelines (for Reviewer)+<!--+This is a flexible checklist for the reviewer to fill in.++Developers:+Add extra tasks to the review using list items.+Skip review tasks using ~~strikethrough~~, or just delete them.+If you want this pull request to have a specific reviewer, tag them in the list of reviewers.++Reviewer:+This checklist can help you do your review.+Add or skip tasks as needed.+-->++**Does this pull request improve Zebra?**++- [ ] Pull Request+ - **Is the pull request complete: code, documentation, and tests?**+ - The PR contains changes to related code (unrelated changes can be split into another PR)+ - The PR does everything listed in the tickets that it closes, or the designs that it finishes+ - Any follow-up tasks are listed in a GitHub issue++- [ ] Code+ - **Does the code implement the specifications or design documents?**+ - Changes from the specifications or design documents are explained in comments+ - The code is readable, and does not appear to have any bugs
The second item seems a little redundant.
- The code prioritizes readability.
comment created time in 3 days
Pull request review commentZcashFoundation/zebra
Add review guidelines to the default PR template
Summarize the solution and provide any necessary context needed to understand the code change. --> +## Follow Up Work++<!--+Is there anything missing from the solution?+What still needs to be done?+-->+ ## Related Issues <!-- Please link to any existing GitHub issues pertaining to this PR. -->++## Review Guidelines (for Reviewer)+<!--+This is a flexible checklist for the reviewer to fill in.++Developers:+Add extra tasks to the review using list items.+Skip review tasks using ~~strikethrough~~, or just delete them.+If you want this pull request to have a specific reviewer, tag them in the list of reviewers.++Reviewer:+This checklist can help you do your review.+Add or skip tasks as needed.+-->++**Does this pull request improve Zebra?**
I think this should be removed, it reads as confrontational to me. I would expect every PR to improve zebra, otherwise it wouldn't have been written, and focusing on this question in the review checklist could be intimidating for new contributors, as though doubts were being cast upon their ability to improve and contribute to the codebase.
comment created time in 3 days
push eventrust-lang/project-error-handling
commit sha 7006d9ff2541daef31777e082cb0df0f3ddb3cc7
Add meetings/2020-10-26.md (#19) * Add meetings/2020-10-26.md * Update 2020-10-26.md Co-authored-by: Jane Lusby <[email protected]>
push time in 3 days
PR merged rust-lang/project-error-handling
Added meeting minutes for 10-26-2020
pr closed time in 3 days
push eventnagashi/project-error-handling
commit sha 1b5d7ae13760fcde5f0be153eccceeec298f8d13
Update 2020-10-26.md
push time in 3 days
issue commentZcashFoundation/zebra
Use Display for Block in errors, logs, and spans
I think height+hash are the fields I'd want most of the time in logs, so that's what I'd put in it.
comment created time in 3 days
pull request commenthttp-rs/http-types
What if we just use
eyredirectly as the error/result type and let e.g. Tide or the end application author install the hook?That still allows the benefits and makes more structural sense. It also means that downstream could choose which reporter (such as color-eyre).
Additionally, perhaps we could make this a build option (feature)? We could then play around with it - I'm willing to try it out in my employer's application. I'm probably going to make my own branch to check things anyways, so I don't mind picking this up.
If you don't mind carrying the StatusCode along side the Report instead of inside, which this PR seems to imply already, then that's definitely the best option. I'm still a little sad about it. I wrote two PRs of different designs I was considering for how we could allow composable error reporting, or even extra handlers that you could push into reports from libraries, but neither of them really seemed like the right solution so they've kinda stalled.
- https://github.com/yaahc/eyre/pull/37
- https://github.com/yaahc/eyre/pull/38
My hope is that we'd eventually be able to consistently store the status code inside of the reporter, and retrieve it, and have little risk of users accidentally discarding them. Not there yet :/
comment created time in 3 days
push eventyaahc/eyre
commit sha 0722bab8eaaf4fd5b8fdf9b0b69bd5a58a516d15
fix missing track caller annotation (#40) * fix missing track caller annotation * (cargo-release) version 0.6.2 * (cargo-release) start next development iteration 0.6.3-alpha.0
push time in 3 days
created tagyaahc/eyre
A trait object based error handling type for easy idiomatic error handling and reporting in Rust applications
created time in 3 days
push eventyaahc/eyre
commit sha ee7862b2155ed240beda08c06699287b55521ca4
(cargo-release) version 0.6.2
commit sha 83e9ecdd5b2a283e2fc686774d77bb4d232c17ca
(cargo-release) start next development iteration 0.6.3-alpha.0
push time in 3 days
pull request commentrust-lang/project-error-handling
these seem to be the minutes from the previous meeting
comment created time in 3 days
issue openedZcashFoundation/zebra
Add prop tests for each type that implements both `IntoSled` and `FromSled`
This should simply be used to verify that the formats we're using to write and read data from sled are consistent. We will write round trip tests for each type that implements FromSled and IntoSled and assert that for arbitrary instances of that type the deserialized representation is equal to the original one.
created time in 3 days
push eventZcashFoundation/zebra
commit sha 5f03e23536278e0052c215357ee76096a3a90379
remove redundant test
push time in 3 days
push eventZcashFoundation/zebra
commit sha 270ff452f61256fe8dddc2dcdea9e3aacf53ec56
fix compiler errors from merge
push time in 4 days
push eventZcashFoundation/zebra
commit sha 971765ab308ea0537bf7af9b2ea5cf32aed121ef
Handle duplicate blocks in zebra-state (#1198) ## Motivation The zebra-state service needs to be able to handle duplicate blocks. ## Solution This implements changes already outlined by [The State RFC](https://zebra.zfnd.org/dev/rfcs/0005-state-updates.html). We check for successfully committed blocks first, since interacting with the queued blocks struct at this point just complicates the implimentation. If the block has not already been committed we then check if the block has already been queued, if not we handle the block normally (normally here being the bit we already had implemented). ## Documentation Changes - [x] Update the state RFC to match the ways this fix departs from the design - the main thing is that I switched the order of checking for duplicates - [x] ~~Add newly added functions to the state rfc~~ Decided not to do this because they're minor getters that don't influence the rest of the design and aren't exposed as part of the API - [x] Document newly added functions inline ## Testing ## Related Issues - fixes https://github.com/ZcashFoundation/zebra/issues/1182 - tracking issue https://github.com/ZcashFoundation/zebra/issues/1049 Co-authored-by: teor <[email protected]>
commit sha 7e4a1323800a568aeb8c191dae3902ab5d1fa3e8
Merge branch 'main' into sled-trees
push time in 4 days
push eventZcashFoundation/zebra
commit sha 971765ab308ea0537bf7af9b2ea5cf32aed121ef
Handle duplicate blocks in zebra-state (#1198) ## Motivation The zebra-state service needs to be able to handle duplicate blocks. ## Solution This implements changes already outlined by [The State RFC](https://zebra.zfnd.org/dev/rfcs/0005-state-updates.html). We check for successfully committed blocks first, since interacting with the queued blocks struct at this point just complicates the implimentation. If the block has not already been committed we then check if the block has already been queued, if not we handle the block normally (normally here being the bit we already had implemented). ## Documentation Changes - [x] Update the state RFC to match the ways this fix departs from the design - the main thing is that I switched the order of checking for duplicates - [x] ~~Add newly added functions to the state rfc~~ Decided not to do this because they're minor getters that don't influence the rest of the design and aren't exposed as part of the API - [x] Document newly added functions inline ## Testing ## Related Issues - fixes https://github.com/ZcashFoundation/zebra/issues/1182 - tracking issue https://github.com/ZcashFoundation/zebra/issues/1049 Co-authored-by: teor <[email protected]>
push time in 4 days
PR merged ZcashFoundation/zebra
<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below.
Bug fixes and new features should include tests.
Contributors guide: https://zebra.zfnd.org/CONTRIBUTING.html -->
Motivation
The zebra-state service needs to be able to handle duplicate blocks
~idempotently. When we receive a CommitBlock request for a block that has
already been queued we should subscribe to the existing channel for sending the
result of commiting that block. If we receive a block that has already been
succesfully committed to the non-finalized or finalized state we should
immediately respond to the request that the block was committed succesfully.~
<!-- Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of as being the motivation for your change. -->
Solution
This implements changes already outlined by The State RFC. We check for successfully committed blocks first, since interacting with the queued blocks struct at this point just complicates the implimentation. If the block has not already been committed we then check if the block has already been queued, if not we handle the block normally (normally here being the bit we already had implemented).
<!-- Summarize the solution and provide any necessary context needed to understand the code change. -->
Documentation Changes
- [x] Update the state RFC to match the ways this fix departs from the design
- the main thing is that I switched the order of checking for duplicates
- [x]
Add newly added functions to the state rfcDecided not to do this because they're minor getters that don't influence the rest of the design and aren't exposed as part of the API - [x] Document newly added functions inline
Testing
Related Issues
- fixes https://github.com/ZcashFoundation/zebra/issues/1182
- tracking issue https://github.com/ZcashFoundation/zebra/issues/1049 <!-- Please link to any existing GitHub issues pertaining to this PR. -->
pr closed time in 4 days
issue closedZcashFoundation/zebra
Panic: hashes must be unique in memory_state
Version
zebrad main branch, 19 October 2020.
Platform
Linux ... 5.4.68 #1-NixOS SMP Sat Sep 26 16:03:16 UTC 2020 x86_64 GNU/Linux
Description
While syncing mainnet blocks, zebrad panicked with a "hashes must be unique" error in memory_state, inside the span zebra_state::service::queue_and_commit_non_finalized_blocks.
I tried this:
Partially syncing mainnet, a sync hang (#1181), then restarting zebrad so sync could continue.
I expected to see this happen:
A successful sync to the tip.
Instead, this happened: [explanation]
A block timeout error, followed by a zebra-state panic.
Metadata
| key | value |
|---|---|
| version | 3.0.0-alpha.0 |
Block Download Error
Error:
0: failed to verify block
1: request timed out
SpanTrace
<details>
SpanTrace:
0: zebrad::components::sync::block_fetch_verify
with hash=00000000024f9794d9cfe1d7ab6e7e23e7fa68dbc00316ea6e9a0c96358f73b4
at zebrad/src/components/sync.rs:615
1: zebrad::components::sync::extend_tips
at zebrad/src/components/sync.rs:434
2: zebrad::components::sync::sync
at zebrad/src/components/sync.rs:169
</details>
State Error
hashes must be unique
SpanTrace
<details>
SpanTrace:
0: zebra_state::service::queue_and_commit_non_finalized_blocks
at zebra-state/src/service.rs:76
1: zebrad::components::sync::block_fetch_verify
with hash=000000000166f4b01559db2831189c088a99943ba2db2b40b4d068412ea16454
at zebrad/src/components/sync.rs:615
2: zebrad::components::sync::obtain_tips
at zebrad/src/components/sync.rs:314
3: zebrad::components::sync::sync
at zebrad/src/components/sync.rs:169
</details>
closed time in 4 days
teor2345
push eventZcashFoundation/zebra
commit sha edd2e12a710be6fbbc60516bb645040914139ff2
Add a comment clarifying why we memswap channels in the state service
push time in 4 days
push eventZcashFoundation/zebra
commit sha ff51c2e0c0638b2115494870a1e789be3fb52f59
build(deps): bump tracing-subscriber from 0.2.13 to 0.2.14 Bumps [tracing-subscriber](https://github.com/tokio-rs/tracing) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/tokio-rs/tracing/releases) - [Commits](https://github.com/tokio-rs/tracing/compare/tracing-subscriber-0.2.13...tracing-subscriber-0.2.14) Signed-off-by: dependabot[bot] <[email protected]>
commit sha b492cabeeed18bc9cb43cc3b63303322d9720c8c
Bind grafana to localhost in metrics instructions Binding grafana to localhost makes it inaccessible from the wider internet, which is a secure default. Since we run docker with host networking, docker containers have access to D-Bus and other security-related services on localhost. So it's risky to also expose them to the wider internet.
commit sha 90e755472cd775826fcb4d98dad0a79e71942962
Add data source instructions to the metrics help
commit sha 672b39a847d85fbd1419315bf8e53b9cd3857a9f
Use MAX_BLOCK_REORG_HEIGHT in zebra-checkpoints MAX_BLOCK_REORG_HEIGHT is 1 less than the constant it replaces. The new calculation is correct: the 100th block is finalized.
commit sha 20dfd0446324a39bc507526583a451deb6a3a473
Reduce maximum checkpoint size in the Zebra code The new limits are 400 blocks and 32 MB.
commit sha f9dc481934b2398899b00f9a024f1308b40606f5
Rebuild the checkpoint lists with smaller checkpoints
commit sha 60322c3d48f2c4c18e9a5689fdc97642687cb29b
Test that the checkpoint list gap is correct If we change the gap, but don't rebuild the lists, `zebrad` hangs with weird errors.
commit sha 7bf2fdd6d7fecce414f461d8e3620a6892401a68
Fix a header level in the state RFC
commit sha 0935b3305a482ddd0999015348fdc864019ffb90
Fix more state RFC function heading sizes
commit sha a9102e8d6d9a8f6e57e61c9014ae309c77480302
Fix State RFC rendering ambiguities
commit sha fb079c2ca17d0089f89d8a8261b42c4f495d2ebf
Replace BlockHeaderHash with block::Hash
commit sha f5a53d9dae9760e7eda5e40049c0e9a1d6760ae4
Update block metrics after async transaction verification
commit sha 2fa3d8a8f495e63ceb83736bd8dad3c9f4ce4836
Add a comment explaining why block metrics follow validation
commit sha bbe4aa47ea57af41f680b6193225e69f5bd1ef9a
Fix whitespace for rustfmt
commit sha a141c336abb6935d98a9472014517faaf1798e51
Actually fix whitespace
commit sha b636660d6a487ecd1fa0f6c137c3963f199fc0a9
zebrad: rename sync::Error alias to BoxError.
commit sha 13daefa7297c9064a09cfb1d7793fd81e6e4a7e0
network: handle request cancellation in Connection We handle request cancellation in two places: before we transition into the AwaitingResponse state, and while we are in AwaitingResponse. We need both places, or else if we started processing a request, we wouldn't process the cancellation until the timeout elapsed. The first is a check that the oneshot is not already canceled. For the second, we wait on a cancellation, either from a timeout or from the tx channel closing.
commit sha 8e709bfa88f8b1b2b798b5c3d53e72b9d81919d9
network: don't fail on unsolicited messages These messages might be unsolicited, or they might be a response to a request we already canceled. So don't fail the whole connection, just drop the message and move on.
commit sha b90581a3d7f8b1f73b33c5f220c21f5235cbc478
zebrad: create a Downloads Stream for syncing. This makes two changes relative to the existing download code: 1. It uses a oneshot to attempt to cancel the download task after it has started; 2. It encapsulates the download creation and cancellation logic into a Downloads struct.
commit sha 5f229d1475a811d389cc894e81a425b2be5dc1ad
zebrad: use Downloads in sync Try to use the better cancellation logic to revert to previous sync algorithm. As designed, the sync algorithm is supposed to proceed by downloading state prospectively and handle errors by flushing the pipeline and starting over. This hasn't worked well, because we didn't previously cancel tasks properly. Now that we can, try to use something in the spirit of the original sync algorithm.
push time in 4 days
push eventZcashFoundation/zebra
commit sha 8217e15c1c779321390debfa91602cd08258e4b4
add version prefix to sled db path and fix rustfmt / clippy warnings
push time in 4 days
push eventZcashFoundation/zebra
commit sha cab96aa1a820560304ca0fdd173de9ac54ee1db0
zebrad: clarify config help text (#1194)
commit sha ff51c2e0c0638b2115494870a1e789be3fb52f59
build(deps): bump tracing-subscriber from 0.2.13 to 0.2.14 Bumps [tracing-subscriber](https://github.com/tokio-rs/tracing) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/tokio-rs/tracing/releases) - [Commits](https://github.com/tokio-rs/tracing/compare/tracing-subscriber-0.2.13...tracing-subscriber-0.2.14) Signed-off-by: dependabot[bot] <[email protected]>
commit sha b492cabeeed18bc9cb43cc3b63303322d9720c8c
Bind grafana to localhost in metrics instructions Binding grafana to localhost makes it inaccessible from the wider internet, which is a secure default. Since we run docker with host networking, docker containers have access to D-Bus and other security-related services on localhost. So it's risky to also expose them to the wider internet.
commit sha 90e755472cd775826fcb4d98dad0a79e71942962
Add data source instructions to the metrics help
commit sha 672b39a847d85fbd1419315bf8e53b9cd3857a9f
Use MAX_BLOCK_REORG_HEIGHT in zebra-checkpoints MAX_BLOCK_REORG_HEIGHT is 1 less than the constant it replaces. The new calculation is correct: the 100th block is finalized.
commit sha 20dfd0446324a39bc507526583a451deb6a3a473
Reduce maximum checkpoint size in the Zebra code The new limits are 400 blocks and 32 MB.
commit sha f9dc481934b2398899b00f9a024f1308b40606f5
Rebuild the checkpoint lists with smaller checkpoints
commit sha 60322c3d48f2c4c18e9a5689fdc97642687cb29b
Test that the checkpoint list gap is correct If we change the gap, but don't rebuild the lists, `zebrad` hangs with weird errors.
commit sha 7bf2fdd6d7fecce414f461d8e3620a6892401a68
Fix a header level in the state RFC
commit sha 0935b3305a482ddd0999015348fdc864019ffb90
Fix more state RFC function heading sizes
commit sha a9102e8d6d9a8f6e57e61c9014ae309c77480302
Fix State RFC rendering ambiguities
commit sha fb079c2ca17d0089f89d8a8261b42c4f495d2ebf
Replace BlockHeaderHash with block::Hash
commit sha f5a53d9dae9760e7eda5e40049c0e9a1d6760ae4
Update block metrics after async transaction verification
commit sha 2fa3d8a8f495e63ceb83736bd8dad3c9f4ce4836
Add a comment explaining why block metrics follow validation
commit sha bbe4aa47ea57af41f680b6193225e69f5bd1ef9a
Fix whitespace for rustfmt
commit sha a141c336abb6935d98a9472014517faaf1798e51
Actually fix whitespace
commit sha b636660d6a487ecd1fa0f6c137c3963f199fc0a9
zebrad: rename sync::Error alias to BoxError.
commit sha 13daefa7297c9064a09cfb1d7793fd81e6e4a7e0
network: handle request cancellation in Connection We handle request cancellation in two places: before we transition into the AwaitingResponse state, and while we are in AwaitingResponse. We need both places, or else if we started processing a request, we wouldn't process the cancellation until the timeout elapsed. The first is a check that the oneshot is not already canceled. For the second, we wait on a cancellation, either from a timeout or from the tx channel closing.
commit sha 8e709bfa88f8b1b2b798b5c3d53e72b9d81919d9
network: don't fail on unsolicited messages These messages might be unsolicited, or they might be a response to a request we already canceled. So don't fail the whole connection, just drop the message and move on.
commit sha b90581a3d7f8b1f73b33c5f220c21f5235cbc478
zebrad: create a Downloads Stream for syncing. This makes two changes relative to the existing download code: 1. It uses a oneshot to attempt to cancel the download task after it has started; 2. It encapsulates the download creation and cancellation logic into a Downloads struct.
push time in 4 days
push eventZcashFoundation/zebra
commit sha 260d30abfc8fd654d92b2df3770e8e93d66df0e9
Apply suggestions from code review Co-authored-by: teor <[email protected]>
push time in 4 days
push eventZcashFoundation/zebra
commit sha b4bd958cce2021bc117cc4ff3cc81794dbd9d7d2
Apply suggestions from code review Co-authored-by: teor <[email protected]>
push time in 4 days
push eventrust-lang/project-error-handling
commit sha b4d9860c588ee24363bad16adcc1ccada52a15b8
error book wip oliver (#18) * error book wip oliver * Update CHARTER.md Co-authored-by: Jane Lusby <[email protected]> * remove ignored dir oliver Co-authored-by: Jane Lusby <[email protected]>
push time in 4 days
PR merged rust-lang/project-error-handling
shares the outline for the error book and introduces some edits for readability in narrow windows
pr closed time in 4 days
Pull request review commentrust-lang/project-error-handling
### Agree on and define common error handling terminology -- Recoverable error: An error that can be reacted and recovered from when encountered e.g. a missing file.-- Unrecoverable error: An error that cannot reasonably be reacted to or recovered from and which indicates a bug e.g. indexing out of bounds.-- Error Type: A type that represents a recoverable error. Error types can optionally implement the `Error` trait so that it can be reported to the user or be converted into a trait object.-- Reporting Type: A type that can store all recoverable errors an application may need to propagate and print them as error reports.- - Reporting types can represent the recoverable errors either via concrete types, likely parameterized, or trait objects.- - Reporting types often bundle context with errors when they are constructed, e.g. `Backtrace`.- - Reporting types often provide helper functions for creating ad hoc errors whose only purpose is to be reported e.g. `anyhow::format_err!` or `eyre::WrapErr`.+- Recoverable error: An error that can be reacted and recovered from when+ encountered e.g. a missing file.+- Unrecoverable error: An error that cannot reasonably be reacted to or+ recovered from and which indicates a bug e.g. indexing out of bounds.+- Error Type: A type that represents a recoverable error. Error types can+ optionally implement the `Error` trait so that it can be reported to the user+ or be converted into a trait object.+- Reporting Type: A type that can store all recoverable errors an application+ may need to propagate and print them as error reports.+- Reporting types can represent the recoverable errors either via concrete+ types, likely parameterized, or trait objects.
Looks like some indentation accidentally got removed here
- Reporting types can represent the recoverable errors either via concrete
types, likely parameterized, or trait objects.
comment created time in 4 days
Pull request review commentrust-lang/project-error-handling
+# pulse
Notes like this should probably be kept to issues / PR comments, rather than committing files like this to the repo
comment created time in 4 days
push eventZcashFoundation/zebra
commit sha c59cc16420646f12eeeaf93e6cc2a518be4815ee
update RFC text
push time in 6 days
push eventZcashFoundation/zebra
commit sha 7566dfb10db5ede724c4f7e54da167ad3ec96663
reject duplicate blocks commits rather than deduplicating them
push time in 6 days
Pull request review commentZcashFoundation/zebra
WIP - Validate shielded coinbase
impl Transaction { ) -> blake2b_simd::Hash { sighash::SigHasher::new(self, hash_type, network_upgrade, input).sighash() }++ /// Access the joinsplits of this transaction, regardless of version.+ // Todo: signature haves to be like:+ // pub fn joinsplits<P: ZkSnarkProof>(&self) -> Option<JoinSplitData<P>> {
I thikn the point of the marker trait is that we cannot ever combine these types into one type, since they're encoded differently. The definition as is describes a function where the caller provides a ZkSnarkProof type, and you return a JointSplitData<P> where P is the exact type they requested. What we want is to return the exact type we actually have depending on which transaction variant self is, rather than having the caller select the expected type for us.
I think the precise signature you'd want to define is something like
fn joinsplits(&self) -> Option<Either<JoinSplitData<Bctv14Proof>, JoinSplitData<Groth16Proof>>>;
comment created time in 6 days
Pull request review commentZcashFoundation/zebra
Run a block sync in CI with 2 large checkpoints
impl<T> TestOutput<T> { return Ok(self); } - Err(eyre!("stdout of command is not equal the given string")).context_from(self)+ Err(eyre!("stdout of command is not equal the given string"))+ .context_from(self)+ .with_section(|| format!("{:?}", s).header("Match String:"))
:fire:
comment created time in 6 days
Pull request review commentZcashFoundation/zebra
Run a block sync in CI with 2 large checkpoints
impl FinalizedState { utxo_by_outpoint: db.open_tree(b"utxo_by_outpoint").unwrap(), // sprout_nullifiers: db.open_tree(b"sprout_nullifiers").unwrap(), // sapling_nullifiers: db.open_tree(b"sapling_nullifiers").unwrap(),+ debug_stop_at_height: config.debug_stop_at_height.map(block::Height),+ };++ if let Some(tip_height) = new_state.finalized_tip_height() {+ new_state.stop_if_at_height_limit(+ StopCheckContext::OnLoad,+ tip_height,+ new_state.finalized_tip_hash(),+ );+ }++ new_state+ }++ /// Synchronously flushes all dirty IO buffers and calls fsync.+ ///+ /// Returns the number of bytes flushed during this call.+ /// See sled's `Tree.flush` for more details.+ pub fn flush(&self) -> sled::Result<usize> {
:+1:
comment created time in 6 days
Pull request review commentZcashFoundation/zebra
Run a block sync in CI with 2 large checkpoints
impl FinalizedState { // for some reason type inference fails here Ok::<_, sled::transaction::ConflictableTransactionError>(hash) },- )- .map_err(Into::into)+ );++ if result.is_ok() {+ self.stop_if_at_height_limit(StopCheckContext::OnCommit, height, hash);
How do you feel about having stop_if_at_height_limit return a bool and flushing if it returns true, then we can remove the whole StopCheckContext enum.
comment created time in 6 days
push eventZcashFoundation/zebra
commit sha 1b102297e245b7d96f8113e7f1d301c826c5aa32
add nullifier trees
push time in 7 days
push eventZcashFoundation/zebra
commit sha 8def574bc210d4a34d41453f47d384e9b3ac1893
Activate the standard pull request template by default Non-default pull request templates can be used via the CLI, or a URL query parameter: https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-automation-for-issues-and-pull-requests-with-query-parameters
commit sha 0856e5d6549057f9761e92daa9d93618a89774a3
build(deps): bump codecov/codecov-action from v1.0.13 to v1.0.14 Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from v1.0.13 to v1.0.14. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Commits](https://github.com/codecov/codecov-action/compare/v1.0.13...7d5dfa54903bd909319c580a00535b483d1efcf3) Signed-off-by: dependabot[bot] <[email protected]>
commit sha 5df0ff4086a2a597bcc2b177fb9ff257fcf71275
Add Clippy (stable) job and continue-on-error Clippy (nightly) job Do not pass -- -D warnings to the Clippy (nightly) job We do _not_ want the nightly job to fail on warnings. Resolves #1156
commit sha db54a623b72e2f7402fb20233e0e7c80d9d8b3d0
Export sighash::HashType
commit sha f9de91716cc75d232c62556ae193b49b2a3be096
Add docstrings for sighash
commit sha 97b6ba10cc9ace05d86f8551dedacd0ac90b3a38
Use redjubjub crate exported from zebra-chain in the redjubjub::Verifier
commit sha 5a78bbb6c953d2f2076a257bd18090fe6757d8a4
Add nullifiers(), and note_commitments() to ShieldedData
commit sha eb56666d3072cbd1584e54792345e53d6eccf76f
chain: add ShieldedData::binding_verification_key()
commit sha 9dc8d76d68889a66824bb12c345fba9427ae039e
consensus: add stub groth16::Verifier Co-authored-by: Deirdre Connolly <[email protected]>
commit sha 248c31890648176d2cf031bacf0116023b439125
consensus: sketch of transaction::Verifier This squashes the previous sequence of commits to let us separate out the structural skeleton (which unblocks other work and is not consensus-critical) from the actual checks (which don't block other work and are consensus-critical). Co-authored-by: Deirdre Connolly <[email protected]>
commit sha 4a36c4485ab1ec05ddf74851e98b2e33248b6908
consensus: integrate script, transaction Verifiers
commit sha 8a64c056fb7a4a703e63e71691b8bae5ee26d1ee
consensus: integrate block, transaction Verifiers
commit sha c0aa1b477ed6e0f683bed50e30b2895be753937c
consensus: add #[source] attributes to chain errors
commit sha d4ce3eb054ec1fad51e88187f30f1d2b31dd4863
consensus: improve docs - remove no longer accurate documentation about transaction verifier; - add description of the role of the crate.
commit sha eb43893de0f0e0f18a8af89c33d24abd4b574109
consensus: minimize API, clean docs This reduces the API surface to the minimum required for functionality, and cleans up module documentation. The stub mempool module is deleted entirely, since it will need to be redone later anyways.
commit sha e796132057654ffa98e130c98d882486a7796ace
Allow dead_code for the transaction::Request for now (mempool)
commit sha a7ef6f6a408a9293ee8b779c547a0303643fe430
Allow dead_code for checkpoint::Verifier for now
commit sha 9549e180c0b96e8cc46b4e637e2ad0d765487590
Allow dead_code on parameters for now
commit sha 1d35c5a0b9b0eeea1a3e0749605381d29b304cc4
Enable the zebrad sync tests by default If your test environment does not have DNS or network access, set the ZEBRA_SKIP_NETWORK_TESTS environmental variable to disable these tests.
commit sha 0343e28d3a97f57c9e297aa7980f169eb4a3cd88
Disable sync test on ubuntu CI runners They don't seem to have DNS or network configured during the tests. Also make capitalisation of step names consistent.
push time in 7 days
push eventZcashFoundation/zebra
commit sha 1c4f31234ead29ad1538cf579f8c46b89d24f5c0
update usage of renamed function
push time in 7 days
push eventZcashFoundation/zebra
commit sha 8684dbb4d3ee0a66d0fbb4eaa17922decdeecb1d
remove unnecessary clone
push time in 7 days
push eventZcashFoundation/zebra
commit sha 09b9e8c5203e5dc3377767861b4210e5ee35ec61
centralize block stop check to finalized state commit
push time in 7 days
push eventZcashFoundation/zebra
commit sha a9dd81a86cd252d95983cb82e7b4bc6dbd41466a
update docs
commit sha 57f9fba3e2a741fd795d678572d2937e09f65779
Merge branch 'duplicate-blocks' of github.com:ZcashFoundation/zebra into duplicate-blocks
push time in 7 days
push eventRustBeginners/awesome-rust-mentors
commit sha 90916adbf66b8579f1e55d9f9352b276985fdec4
Fixed misplaced paren (#148)
push time in 7 days
PR merged RustBeginners/awesome-rust-mentors
pr closed time in 7 days