profile
viewpoint
Jane Lusby yaahc The Zcash Foundation San Francisco https://yaah.dev Rust, Linux, distributed systems, storage, networking, error handling

rust-lang/rust-clippy 5154

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

hawkw/mycelium 19

🍄

yaahc/adhocerr 4

Crate for the quick creation of anonymous error types from strings

iykekings/deno_doctest 3

Proposal on how deno doctest will work, inspired by rustdoc --test

yaahc/btparse 3

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

Jane Lusby

commit sha 7d4bdba7b03a2da7d6562970be6e46c7799185ec

revert unnecessary change in sync_until

view details

push time in 10 hours

push eventZcashFoundation/zebra

Jane Lusby

commit sha b9dec28be9f917b83a78c0c0ac0caadb6002a9aa

further make use statement consistent

view details

push time in 10 hours

push eventZcashFoundation/zebra

Jane Lusby

commit sha 30e308a299ccc0f9de539c4c82aefe892d87b6db

fix use cfg

view details

push time in 10 hours

push eventZcashFoundation/zebra

Jane Lusby

commit sha a18d1555d1abf4fed4de5409d8fb4a06851ca2c8

update acceptance tests

view details

push time in 10 hours

issue commentyaahc/eyre

Something like `ContextCompat` but for options only

Would you consider adding something like OptionContext which would add .context for 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 :(

imbolc

comment created time in 16 hours

PullRequestReviewEvent

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.

teor2345

comment created time in 16 hours

PullRequestReviewEvent

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

teor2345

comment created time in 16 hours

PullRequestReviewEvent

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

yaahc

comment created time in a day

push eventZcashFoundation/zebra

Jane Lusby

commit sha 518ae6b2e5d44560ca72177f88bf0e8b8da61d29

Update .github/pull_request_template.md Co-authored-by: teor <teor@riseup.net>

view details

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:

teor2345

comment created time in 2 days

PullRequestReviewEvent

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

yaahc

comment created time in 2 days

create barnchZcashFoundation/zebra

branch : sapling-sync-test

created branch time in 2 days

PR opened ZcashFoundation/zebra

Add network integration test for quick post sapling sync testing

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.

+60 -4

0 comment

1 changed file

pr created time in 2 days

push eventtokio-rs/tracing

David

commit sha 19af2924f1bcf9c458264a420adc5b77ae17e93e

chore: fix tracing-macros::dbg (#1054) …and the `factorial` example.

view details

dependabot-preview[bot]

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] <support@dependabot.com> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>

view details

Eliza Weisman

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: ![image](https://user-images.githubusercontent.com/2796466/96798681-3fc85000-13b6-11eb-9e85-7602d918ee09.png) 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 <eliza@buoyant.io>

view details

David

commit sha 0dc8ef2da97f605689fff17f6c38b69e105a5281

subscriber: remove TraceLogger (#1052) * Remove TraceLogger The `TraceLogger` implementation is deprecated and this PR removes it completely.

view details

Veetaha

commit sha b7b14df21943480c2a425f0510634cf9e5ce61b1

chore: fix rustdoc warning in tracing-subscriber (#1061)

view details

David Barsky

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 <dbarsky@amazon.com> Co-authored-by: Eliza Weisman <eliza@buoyant.io>

view details

David Barsky

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.

view details

Eliza Weisman

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

view details

Eliza Weisman

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 <eliza@buoyant.io>

view details

Eliza Weisman

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: ![Screenshot_20201024_122857](https://user-images.githubusercontent.com/2796466/97093422-a2ad2780-1600-11eb-94bf-ee13011a3e73.png) ...and after: ![Screenshot_20201024_133352](https://user-images.githubusercontent.com/2796466/97093410-8e692a80-1600-11eb-9b42-1aefa1725957.png) Signed-off-by: Eliza Weisman <eliza@buoyant.io>

view details

David

commit sha eadf2a23da21cc1e9572ed223fe386ef956e1afe

chore: Fix several renames missed in #1015 (#1066) The changes were in tests, tracing-error, and example.

view details

Jane Lusby

commit sha 9b09d13399b87d55253943c180074d19e7701265

Merge branch 'master' into traced-error-map

view details

push time in 2 days

push eventtokio-rs/tracing

Jane Lusby

commit sha b83cbbce9205a95940bd130a6f197fee13b38a3e

Apply suggestions from code review Co-authored-by: Eliza Weisman <eliza@buoyant.io>

view details

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.

hdevalence

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentyaahc/color-eyre

Support for custom styles

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.

d4h0

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

yaahc

comment created time in 2 days

pull request commenthttp-rs/http-types

Eyre

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.

jbr

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

yaahc

comment created time in 2 days

push eventtokio-rs/tracing

Jane Lusby

commit sha b2e5e7d454c1e081d3332d764e870d7bf87b17fe

Add example for err_into

view details

Jane Lusby

commit sha 00e8922dbfc1d6450676a0879038d2313ff60b01

Merge branch 'traced-error-map' of github.com:tokio-rs/tracing into traced-error-map

view details

push time in 2 days

push eventtokio-rs/tracing

Jane Lusby

commit sha 375ba5df3b908b132009598ca1faf6206923d03d

Update tracing-error/src/error.rs Co-authored-by: Eliza Weisman <eliza@buoyant.io>

view details

push time in 2 days

push eventtokio-rs/tracing

Jane Lusby

commit sha 8c82fffa3eb5f410f7df9f87a90d9a528f068373

add a doc comment

view details

push time in 2 days

PullRequestReviewEvent

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.

yaahc

comment created time in 2 days

push eventtokio-rs/tracing

Jane Lusby

commit sha fff00900d1965c1a7d0e55c86adc98c4fd6d7e96

Add example usage for map-traced-error

view details

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...

yaahc

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventtokio-rs/tracing

Jane Lusby

commit sha 3b965aa335e674061dc109f2acf25410aa2671ab

add new fn and err_into

view details

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.
teor2345

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

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.
teor2345

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.

teor2345

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventrust-lang/project-error-handling

Charles "Chas" O'Riley

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 <jlusby42@gmail.com>

view details

push time in 3 days

PR merged rust-lang/project-error-handling

Add meetings/2020-10-26.md

Added meeting minutes for 10-26-2020

+123 -0

2 comments

1 changed file

nagashi

pr closed time in 3 days

push eventnagashi/project-error-handling

Jane Lusby

commit sha 1b5d7ae13760fcde5f0be153eccceeec298f8d13

Update 2020-10-26.md

view details

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.

teor2345

comment created time in 3 days

pull request commenthttp-rs/http-types

Eyre

What if we just use eyre directly 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 :/

jbr

comment created time in 3 days

delete branch yaahc/eyre

delete branch : track-caller-fix

delete time in 3 days

push eventyaahc/eyre

Jane Lusby

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

view details

push time in 3 days

PR merged yaahc/eyre

fix missing track caller annotation
+9 -3

0 comment

3 changed files

yaahc

pr closed time in 3 days

created tagyaahc/eyre

tagv0.6.2

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

Jane Lusby

commit sha ee7862b2155ed240beda08c06699287b55521ca4

(cargo-release) version 0.6.2

view details

Jane Lusby

commit sha 83e9ecdd5b2a283e2fc686774d77bb4d232c17ca

(cargo-release) start next development iteration 0.6.3-alpha.0

view details

push time in 3 days

create barnchyaahc/eyre

branch : track-caller-fix

created branch time in 3 days

PR opened yaahc/eyre

fix missing track caller annotation
+3 -0

0 comment

2 changed files

pr created time in 3 days

pull request commentrust-lang/project-error-handling

Add meetings/2020-10-26.md

these seem to be the minutes from the previous meeting

nagashi

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

Jane Lusby

commit sha 5f03e23536278e0052c215357ee76096a3a90379

remove redundant test

view details

push time in 3 days

PullRequestReviewEvent

push eventZcashFoundation/zebra

Jane Lusby

commit sha 270ff452f61256fe8dddc2dcdea9e3aacf53ec56

fix compiler errors from merge

view details

push time in 4 days

push eventZcashFoundation/zebra

Jane Lusby

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 <teor@riseup.net>

view details

Jane Lusby

commit sha 7e4a1323800a568aeb8c191dae3902ab5d1fa3e8

Merge branch 'main' into sled-trees

view details

push time in 4 days

push eventZcashFoundation/zebra

Jane Lusby

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 <teor@riseup.net>

view details

push time in 4 days

delete branch ZcashFoundation/zebra

delete branch : duplicate-blocks

delete time in 4 days

PR merged ZcashFoundation/zebra

Handle duplicate blocks in zebra-state

<!-- 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 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 <!-- Please link to any existing GitHub issues pertaining to this PR. -->
+86 -38

5 comments

4 changed files

yaahc

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

Jane Lusby

commit sha edd2e12a710be6fbbc60516bb645040914139ff2

Add a comment clarifying why we memswap channels in the state service

view details

push time in 4 days

push eventZcashFoundation/zebra

dependabot[bot]

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] <support@github.com>

view details

teor

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.

view details

teor

commit sha 90e755472cd775826fcb4d98dad0a79e71942962

Add data source instructions to the metrics help

view details

teor

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.

view details

teor

commit sha 20dfd0446324a39bc507526583a451deb6a3a473

Reduce maximum checkpoint size in the Zebra code The new limits are 400 blocks and 32 MB.

view details

teor

commit sha f9dc481934b2398899b00f9a024f1308b40606f5

Rebuild the checkpoint lists with smaller checkpoints

view details

teor

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.

view details

teor

commit sha 7bf2fdd6d7fecce414f461d8e3620a6892401a68

Fix a header level in the state RFC

view details

teor

commit sha 0935b3305a482ddd0999015348fdc864019ffb90

Fix more state RFC function heading sizes

view details

teor

commit sha a9102e8d6d9a8f6e57e61c9014ae309c77480302

Fix State RFC rendering ambiguities

view details

teor

commit sha fb079c2ca17d0089f89d8a8261b42c4f495d2ebf

Replace BlockHeaderHash with block::Hash

view details

teor

commit sha f5a53d9dae9760e7eda5e40049c0e9a1d6760ae4

Update block metrics after async transaction verification

view details

teor

commit sha 2fa3d8a8f495e63ceb83736bd8dad3c9f4ce4836

Add a comment explaining why block metrics follow validation

view details

teor

commit sha bbe4aa47ea57af41f680b6193225e69f5bd1ef9a

Fix whitespace for rustfmt

view details

teor

commit sha a141c336abb6935d98a9472014517faaf1798e51

Actually fix whitespace

view details

Henry de Valence

commit sha b636660d6a487ecd1fa0f6c137c3963f199fc0a9

zebrad: rename sync::Error alias to BoxError.

view details

Henry de Valence

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.

view details

Henry de Valence

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.

view details

Henry de Valence

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.

view details

Henry de Valence

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.

view details

push time in 4 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha 8217e15c1c779321390debfa91602cd08258e4b4

add version prefix to sled db path and fix rustfmt / clippy warnings

view details

push time in 4 days

push eventZcashFoundation/zebra

Henry de Valence

commit sha cab96aa1a820560304ca0fdd173de9ac54ee1db0

zebrad: clarify config help text (#1194)

view details

dependabot[bot]

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] <support@github.com>

view details

teor

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.

view details

teor

commit sha 90e755472cd775826fcb4d98dad0a79e71942962

Add data source instructions to the metrics help

view details

teor

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.

view details

teor

commit sha 20dfd0446324a39bc507526583a451deb6a3a473

Reduce maximum checkpoint size in the Zebra code The new limits are 400 blocks and 32 MB.

view details

teor

commit sha f9dc481934b2398899b00f9a024f1308b40606f5

Rebuild the checkpoint lists with smaller checkpoints

view details

teor

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.

view details

teor

commit sha 7bf2fdd6d7fecce414f461d8e3620a6892401a68

Fix a header level in the state RFC

view details

teor

commit sha 0935b3305a482ddd0999015348fdc864019ffb90

Fix more state RFC function heading sizes

view details

teor

commit sha a9102e8d6d9a8f6e57e61c9014ae309c77480302

Fix State RFC rendering ambiguities

view details

teor

commit sha fb079c2ca17d0089f89d8a8261b42c4f495d2ebf

Replace BlockHeaderHash with block::Hash

view details

teor

commit sha f5a53d9dae9760e7eda5e40049c0e9a1d6760ae4

Update block metrics after async transaction verification

view details

teor

commit sha 2fa3d8a8f495e63ceb83736bd8dad3c9f4ce4836

Add a comment explaining why block metrics follow validation

view details

teor

commit sha bbe4aa47ea57af41f680b6193225e69f5bd1ef9a

Fix whitespace for rustfmt

view details

teor

commit sha a141c336abb6935d98a9472014517faaf1798e51

Actually fix whitespace

view details

Henry de Valence

commit sha b636660d6a487ecd1fa0f6c137c3963f199fc0a9

zebrad: rename sync::Error alias to BoxError.

view details

Henry de Valence

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.

view details

Henry de Valence

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.

view details

Henry de Valence

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.

view details

push time in 4 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha 260d30abfc8fd654d92b2df3770e8e93d66df0e9

Apply suggestions from code review Co-authored-by: teor <teor@riseup.net>

view details

push time in 4 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha b4bd958cce2021bc117cc4ff3cc81794dbd9d7d2

Apply suggestions from code review Co-authored-by: teor <teor@riseup.net>

view details

push time in 4 days

push eventrust-lang/project-error-handling

o752d

commit sha b4d9860c588ee24363bad16adcc1ccada52a15b8

error book wip oliver (#18) * error book wip oliver * Update CHARTER.md Co-authored-by: Jane Lusby <jlusby42@gmail.com> * remove ignored dir oliver Co-authored-by: Jane Lusby <jlusby42@gmail.com>

view details

push time in 4 days

PR merged rust-lang/project-error-handling

error book wip oliver

shares the outline for the error book and introduces some edits for readability in narrow windows

+186 -66

0 comment

30 changed files

o752d

pr closed time in 4 days

PullRequestReviewEvent

Pull request review commentrust-lang/project-error-handling

error book wip oliver

  ### 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.
o752d

comment created time in 4 days

Pull request review commentrust-lang/project-error-handling

error book wip oliver

+# pulse

Notes like this should probably be kept to issues / PR comments, rather than committing files like this to the repo

o752d

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventZcashFoundation/zebra

Jane Lusby

commit sha c59cc16420646f12eeeaf93e6cc2a518be4815ee

update RFC text

view details

push time in 6 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha 7566dfb10db5ede724c4f7e54da167ad3ec96663

reject duplicate blocks commits rather than deduplicating them

view details

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>>>;
oxarbitrage

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

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:

teor2345

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:

teor2345

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.

teor2345

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventZcashFoundation/zebra

Jane Lusby

commit sha 1b102297e245b7d96f8113e7f1d301c826c5aa32

add nullifier trees

view details

push time in 7 days

push eventZcashFoundation/zebra

teor

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

view details

dependabot[bot]

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] <support@github.com>

view details

Deirdre Connolly

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

view details

Deirdre Connolly

commit sha db54a623b72e2f7402fb20233e0e7c80d9d8b3d0

Export sighash::HashType

view details

Deirdre Connolly

commit sha f9de91716cc75d232c62556ae193b49b2a3be096

Add docstrings for sighash

view details

Deirdre Connolly

commit sha 97b6ba10cc9ace05d86f8551dedacd0ac90b3a38

Use redjubjub crate exported from zebra-chain in the redjubjub::Verifier

view details

Deirdre Connolly

commit sha 5a78bbb6c953d2f2076a257bd18090fe6757d8a4

Add nullifiers(), and note_commitments() to ShieldedData

view details

Deirdre Connolly

commit sha eb56666d3072cbd1584e54792345e53d6eccf76f

chain: add ShieldedData::binding_verification_key()

view details

Henry de Valence

commit sha 9dc8d76d68889a66824bb12c345fba9427ae039e

consensus: add stub groth16::Verifier Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>

view details

Henry de Valence

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 <deirdre@zfnd.org>

view details

Jane Lusby

commit sha 4a36c4485ab1ec05ddf74851e98b2e33248b6908

consensus: integrate script, transaction Verifiers

view details

Jane Lusby

commit sha 8a64c056fb7a4a703e63e71691b8bae5ee26d1ee

consensus: integrate block, transaction Verifiers

view details

Jane Lusby

commit sha c0aa1b477ed6e0f683bed50e30b2895be753937c

consensus: add #[source] attributes to chain errors

view details

Henry de Valence

commit sha d4ce3eb054ec1fad51e88187f30f1d2b31dd4863

consensus: improve docs - remove no longer accurate documentation about transaction verifier; - add description of the role of the crate.

view details

Henry de Valence

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.

view details

Deirdre Connolly

commit sha e796132057654ffa98e130c98d882486a7796ace

Allow dead_code for the transaction::Request for now (mempool)

view details

Deirdre Connolly

commit sha a7ef6f6a408a9293ee8b779c547a0303643fe430

Allow dead_code for checkpoint::Verifier for now

view details

Deirdre Connolly

commit sha 9549e180c0b96e8cc46b4e637e2ad0d765487590

Allow dead_code on parameters for now

view details

teor

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.

view details

teor

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.

view details

push time in 7 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha 1c4f31234ead29ad1538cf579f8c46b89d24f5c0

update usage of renamed function

view details

push time in 7 days

PullRequestReviewEvent

push eventZcashFoundation/zebra

Jane Lusby

commit sha 8684dbb4d3ee0a66d0fbb4eaa17922decdeecb1d

remove unnecessary clone

view details

push time in 7 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha 09b9e8c5203e5dc3377767861b4210e5ee35ec61

centralize block stop check to finalized state commit

view details

push time in 7 days

push eventZcashFoundation/zebra

Jane Lusby

commit sha a9dd81a86cd252d95983cb82e7b4bc6dbd41466a

update docs

view details

Jane Lusby

commit sha 57f9fba3e2a741fd795d678572d2937e09f65779

Merge branch 'duplicate-blocks' of github.com:ZcashFoundation/zebra into duplicate-blocks

view details

push time in 7 days

push eventRustBeginners/awesome-rust-mentors

Aaron Hill

commit sha 90916adbf66b8579f1e55d9f9352b276985fdec4

Fixed misplaced paren (#148)

view details

push time in 7 days

PullRequestReviewEvent
more