Describe the bug

When a fallback hook is set, the context (if not another hook is set) will run the hook, so the output will be

invalid input parameter
├╴test.rs:10:18
╰╴Frame { location: Location { file: "test.rs", line: 10, col: 18 }, context: Kind(InvalidInput) }

while the last printed attachment is emitted by the fallback with the context frame

To reproduce

use std::io::{Error, ErrorKind};

use error_stack::Report;

fn main() {
    Report::install_debug_hook_fallback(|frame, ctx| {
        ctx.push_body(format!("{frame:?}"));
    });

    let report = Report::new(Error::from(ErrorKind::InvalidInput));

    println!("{report:?}");
}

Expected behavior

The context should not be appended as an attachment as well, so the output should be

invalid input parameter
╰╴test.rs:10:18

Rust compiler

1.63 and 1.65.0-nightly (2022-08-26)

Host

aarch64-apple-darwin

Target

aarch64-apple-darwin

Version

latest git revision (cf5d85e)

Features

all

Related Problem

The problem I have seen is that when calling .into_report() on errors, Report only includes the top-most error, and does not include any of the sources.

Proposed Solution

I propose that .into_report() go through the source chain and add each source entry as a printable attachment, (or context frame?) to the error.

Alternatives

No response

Additional context

I've run into this problem using the Rust AWS SDK, where SdkError results in generic "service error" messages, where in reality, if we were to follow the error source chain, we would get all the information we'd need to diagnose and fix the error.

Context

We'd like to be able to load the contents of our blocks directory into the HASH Storybook instance (not to be confused with that recently set up in the Block Protocol repository):

• HASH Storybook in this repo
• HASH Storybook deployed location

There are a number of different ways we could probably go about making blocks accessible within Storybook, including through the use of the Þ Dock (aka. mock-block-dock, or "MBD") as a decorator, wrapped into a Block Protocol add-on for Storybook.

How a Þ Storybook add-on might work

Functionality

Flesh this out

We would create an add-on for Storybook.

We would use the Þ Dock as a decorator: https://storybook.js.org/docs/react/writing-stories/decorators

Location in monorepo

The code for the add-on would likely live within the blockprotocol repository's libs folder.

Publishing the add-on

Once functional, the Storybook add-on could be published to npm and the add-on itself even listed in the public Storybook integrations library. The add-on could then be imported for use within both the # and Þ Storybook instances.

Follow-ups

Unblocks H-3 and H-5.

Calls to external services are currently disabled in cloud experiment runs, so Mapbox API calls that work in hCore don't currently work when running simulations on the HASH simulation cloud.

This is related to rust-lang/rust-mode#452.
I won't repost all the information from there.

Since trying to make rust-mode also parse this particular type of error seems a bit cumbersome, I think it may make sense to add a .dir-locals.el file that somebody can drop into their project.

Describe the bug

When compiling on 1.65.0-beta, the following error occurs:

error[E0658]: use of unstable library feature 'backtrace_frames'
   --> src/fmt/hook.rs:823:23
    |
823 |             backtrace.frames().len(),
    |                       ^^^^^^
    |
    = note: see issue #79676 <https://github.com/rust-lang/rust/issues/79676> for more information

To reproduce

No response

Expected behavior

No response

Rust compiler

1.65.0-beta

Host

aarch64-apple-darwin

Target

aarch64-apple-darwin

Version

latest git revision (cf5d85e)

Features

std

Additional context

No response

error /Users/matteogauthier/dev/blocks/user-profile/node_modules/mock-block-dock: Command failed.
Exit code: 127
Command: yarn build
Arguments: 
Directory: /Users/matteogauthier/dev/blocks/user-profile/node_modules/mock-block-dock
Output:
yarn run v1.22.17
$ yarn clean; yarn build:cjs; yarn build:esm
$ rimraf ./dist/
/bin/sh: rimraf: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
$ tsc --p tsconfig.build.json --module commonjs --outDir dist/cjs 
/bin/sh: tsc: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
$ tsc --p tsconfig.build.json
/bin/sh: tsc: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documenta

the postinstall seems to use tsc which is not installed locally

I found that std::result::Result<T, error_stack::Report<anyhow::Error>> doesn't implement error_stack::IntoReport, so if I try to take an error from a crate that uses anyhow and call .report(), i get some errors. Is this an incompatibility with anyhow, or did I set up my project wrong?

I made a custom error type that implements std::error::Error and std::fmt::Display and tried implementing std::convert::From<anyhow::Error> for my custom type. But to no avail.

Related Problem

When using a library (such as Apache Arrow) that returns it's own non-error stack error types, I sometimes find there is a lot of boilerplate for handling this. For instance, running three "kernels" from arrow may become:

arrow::method1(...).into_report().change_context(Error::Internal)?;
arrow::method2(...).into_report().change_context(Error::Internal)?;
arrow::method3(...).into_report().change_context(Error::Internal)?;

I sometimes wish there was a way to say "allow an automatic conversion from Result<T, arrow::error::Error> to error_stack::Result<T, C> for my error type.

Proposed Solution

I believe such an automatic conversion could be handled by implementing From for arbitrary error types and contexts. Something like:

trait ForError<E> {
  fn for_error(source: &E) -> Self;
}

impl<C> From<E> for error_stack::Report<C> where C: ForError<E> {
  #[track_caller]
  fn from(source: E) -> Self {
    let context = source.for_error();
    source.into_report().change_context(context)
  }
}

Then, I believe that I could do:

enum MyError {
  ...,
  ArrowError,
}

impl ForError<arrow::error::Error> for MyError {
  fn for_error(_: &arrow::error::Error) -> Self {
    Self
  }
}

Alternatives

I've considered (and at times do) break out the methods that all have the same type of error into a helper that returns error_context::Result<T, arrow::error::Error>. This lets me rely on the existing automatic call to .into_report(), and then assign the context "outside". This breaks down when there is a step in between some of the Arrow calls that needs to return a different kind of error, since there is no longer a compatible error type.

Additional context

No response

Cargo fails to find package error-stack on Windows x64
Here is my main.rs from the crates.io Example:

use std::fmt;

use error_stack::{Context, IntoReport, Report, Result, ResultExt};

#[derive(Debug)]
struct ParseExperimentError;

impl fmt::Display for ParseExperimentError {
    fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt.write_str("invalid experiment description")
    }
}

impl Context for ParseExperimentError {}

fn parse_experiment(description: &str) -> Result<(u64, u64), ParseExperimentError> {
    let value = description
        .parse()
        .report()
        .attach_printable_lazy(|| format!("{description:?} could not be parsed as experiment"))
        .change_context(ParseExperimentError)?;

    Ok((value, 2 * value))
}

#[derive(Debug)]
struct ExperimentError;

impl fmt::Display for ExperimentError {
    fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt.write_str("Experiment error: Could not run experiment")
    }
}

impl Context for ExperimentError {}

fn start_experiments(
    experiment_ids: &[usize],
    experiment_descriptions: &[&str],
) -> Result<Vec<u64>, ExperimentError> {
    let experiments = experiment_ids
        .iter()
        .map(|exp_id| {
            let description = experiment_descriptions.get(*exp_id).ok_or_else(|| {
                Report::new(ExperimentError)
                    .attach_printable(format!("Experiment {exp_id} has no valid description"))
            })?;

            let experiment = parse_experiment(description)
                .attach_printable(format!("Experiment {exp_id} could not be parsed"))
                .change_context(ExperimentError)?;

            Ok(move || experiment.0 * experiment.1)
        })
        .collect::<Result<Vec<_>, ExperimentError>>()
        .attach_printable("Unable to setup experiments")?;

    Ok(experiments.iter().map(|experiment| experiment()).collect())
}

fn main() -> Result<(), ExperimentError> {
    let experiment_ids = &[0, 2];
    let experiment_descriptions = &["10", "20", "3o"];
    start_experiments(experiment_ids, experiment_descriptions)?;

    Ok(())
}

I added error-stack to the Cargo.toml like so:

[package]
name = "hello_there"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
error-stack = "0.1.1"

Cargo run produces this result:

error: no matching package named error-stack found
location searched: registry crates-io

Cargo version:
cargo 1.59.0 (49d8809dc 2022-02-10)
rustc version:
rustc 1.59.0 (9d1b2106e 2022-02-23)

Hi, really glad to have the useful lib error-stack. Here maybe small mismatch:

While the examples in README.md and examples folder are all using into_report() in the mainline code, the release version v0.1.1 in crates.io and the corresponding documentations are using report(). So it might be helpful to release a new version of error-stack to match the example and README.

Just a minor suggestion.

Describe the bug

The Graph API returns an internal server error when comparing two boolean parameters in the filter (to return all entities). This is not the case for the comparison of string parameters.

{
  "filter": {
    "equal": [{"parameter": true}, {"parameter": true}]
  },
  "graphResolveDepths": {
    "inheritsFrom": {
      "outgoing": 0
    },
    "constrainsValuesOn": {
      "outgoing": 0
    },
    "constrainsPropertiesOn": {
      "outgoing": 0
    },
    "constrainsLinksOn": {
      "outgoing": 0
    },
    "constrainsLinkDestinationsOn": {
      "outgoing": 0
    },
    "isOfType": {
      "outgoing": 0
    },
    "hasLeftEntity": {
      "outgoing": 0,
      "incoming": 0
    },
    "hasRightEntity": {
      "outgoing": 0,
      "incoming": 0
    }
  }
}

Error Log

external-services-graph-1                |   2022-12-14T12:47:31.015627Z ERROR graph::api::rest::entity: Could not read entities from the store, error: Could not query from store
external-services-graph-1                | ├╴ /usr/local/src/hash_graph/lib/graph/src/store/postgres/knowledge/entity/read.rs:81:14
external-services-graph-1                | │
external-services-graph-1                | ╰─▶ error serializing parameter 0: cannot convert between the Rust type `bool` and the Postgres type `text`
external-services-graph-1                |     ├╴ /usr/local/src/hash_graph/lib/graph/src/store/postgres/knowledge/entity/read.rs:80:14
external-services-graph-1                |     ╰╴ backtrace with 205 frames (1)

To reproduce

1. POST /entites/query with the payload described above

Expected behavior

Returns all entities

Device

No response

Operating system

No response

Browser

No response

Additional context

No response

Describe the bug
Two different iter modules are defined in the top level. This is because pub mod iter defines one module and the blanket import from mod ext will import another module.

Asana Ticket (internal)

To reproduce
Create the documentation and look at the module list

Screenshots

Desktop:

• OS: macOS
• rustc: nightly-2020-08-08
• target: aarch64-apple-darwin
• Version: main branch
• Features: any

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: .github/renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Regex Manager contains disallowed fields: enabled, extends, automerge, schedule, Regex Manager contains disallowed fields: enabled, matchDepTypes, matchPackagePatterns, excludePackageNames, automerge, schedule, Regex Manager contains disallowed fields: enabled, matchPackagePatterns, automerge, schedule, regexManagers[2].excludePackageNames: excludePackageNames should be inside a 'packageRule' only, regexManagers[2].matchDepTypes: matchDepTypes should be inside a 'packageRule' only, regexManagers[2].matchPackagePatterns: matchPackagePatterns should be inside a 'packageRule' only, regexManagers[4].matchPackagePatterns: matchPackagePatterns should be inside a 'packageRule' only

This is the tracking issue for all type implementations needed for deer. Separated by crate name.

Every type is/will be assigned to a PR. A merged PR indicates that the support for that type has landed in the repo. The checkmark is about the status in the linked PR. If it is checked, the type has been implemented and tested.

Due to the sheer number of types, it is easy to forget what part has been completed. For (partially) incomplete implementations, a sublist is provided. If that sublist is no longer present, the implementation for that specific type can be considered complete.

Current reflection is not tested. This will be changed in an upcoming PR

• core
  • bool(#1516)
    • Tests (Reflection)
  • f* (#1516)
    • Tests (Reflection)
  • u*(#1516)
    • Tests (Reflection)
  • i* (#1516)
    • Tests (Reflection)
  • char (#1516)
    • Tests (Reflection)
  • &str (#1516)
    • Tests (Reflection)
  • &[u8] (#2389)
    • Tests (Reflection)
  • [T; N] (#1516)
    • Tests (Reflection)
  • AtomicBool (#1516)
    • Tests (Reflection)
  • AtomicU* (#1516)
    • Tests (Reflection)
  • AtomicI* (#1516)
    • Tests (Reflection)
  • NonZeroU* (#1516)
    • Tests (Reflection)
  • NonZeroI*(#1516)
    • Tests (Reflection)
  • () (#1516)
    • Tests (Reflection)
  • tuples (#2418)
    • Tests (Reflection)
  • LazyCell (nightly) (removed because unsuitable)
  • OnceCell (nightly) (#2376)
  • SyncUnsafeCell (nightly) (#2376)
  • Cell (#2376)
  • RefCell(#2376)
  • UnsafeCell (#2376)
  • PhantomData (#2379)
    • Tests (Reflection)
  • ManuallyDrop (#2384)
  • Option (#2383)
    • Tests (Reflection)
  • Result (#2387)
    • Tests (Reflection)
  • Wrapping (#2378)
  • Saturating (nightly) (#2378)
  • Range* (#2422)
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Bound (#2422)
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Reverse (#2385)
  • Ordering (#2385)
    • Tests (Reflection)
  • Duration (#2390)
    • Tests (Reflection)
  • Exclusive (nightly) (#2386)
• alloc
  • Cow
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Box
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • ThinBox (nightly)
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • BinaryHeap
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • BTreeMap
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • BTreeSet
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • LinkedList
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • VecDeque
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Vec
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • CString
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Box<CStr>
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Rc
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • String
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Arc
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
• std
  • HashMap
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • &Path
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • PathBuf
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Box<Path>
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Mutex
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • RwLock
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • OsString
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • SystemType
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Ip*
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)
  • Socket*
    • Implementation
    • Tests (Deserialization)
    • Tests (Reflection)

We want the headings on HDEV blog posts (such as https://hash.dev/blog/block-protocol-0-3-wordpress) to be individually linkable.

We should render a 'link' icon next to them on-hover, similar to what we already do on https://blockprotocol.org/docs, allowing a direct link to a heading/section to be copied to a user's clipboard. They should also function similarly when clicked, jumping a user down to that section.

_{From SyncLinear.com | H-2}

Related Problem

I find myself often writing code that looks like:

some_call()
  .into_report()
  .change_context(Error::A)?;
some_other_call()
  .into_report()
  .change_context(Error::B)?;
...

This arises when calling libraries that don't return errors using error stack (or worse -- do so using anyhow since I'm in the middle of migrating).

Proposed Solution

I think it should be possible to implement change_context for types that are not already Report<E>. For instance, if reports and anyhow::Error could be used with IntoReport, then the ResultExt trait could be implemented for any result containing an error that implements IntoReport. This would allow the original code to be written as:

some_call()
  .change_context(Error::A)?;
some_other_call()
  .change_context(Error::B)?;
...

### Alternatives

_No response_

### Additional context

_No response_

I found that std::result::Result<T, error_stack::Report<anyhow::Error>> doesn't implement error_stack::IntoReport, so if I try to take an error from a crate that uses anyhow and call .report(), i get some errors. Is this an incompatibility with anyhow, or did I set up my project wrong?

I made a custom error type that implements std::error::Error and std::fmt::Display and tried implementing std::convert::From<anyhow::Error> for my custom type. But to no avail.

Describe the bug

On stable, downcast_ref is used for the hooks, on nightly request_ref and request_value is used. For attachments, this is the same as attachments only provide themself, but for contexts do not provide themself. When installing a hook for e.g. io::Error and use io::Error as context, the output is different:

stable:

invalid input parameter
├╴test.rs:10:18
╰╴invalid input parameter

nightly:

invalid input parameter
╰╴test.rs:10:18

To reproduce

use std::io::{Error, ErrorKind};

use error_stack::Report;

fn main() {
    Report::install_debug_hook::<Error>(|error, ctx| {
        ctx.push_body(error.to_string());
    });

    let report = Report::new(Error::from(ErrorKind::InvalidInput));

    println!("{report:?}");
}

Expected behavior

The output should be the same and stable and on nightly.

Rust compiler

1.63 and 1.65.0-nightly (2022-08-26)

Host

aarch64-apple-darwin

Target

aarch64-apple-darwin

Version

cf5d85e

Features

all

Additional context

As a Context does not provide itself, the same behavior should be emulated on stable as well. As provisioning is not supported on stable, a Context frame can simply be ignored.

The other solution would be to provide the context frame as well.

nightly-2022-07-20 (rust 1.64 stable) introduced rust-lang/rust#98320, which means that the UI and acceptance tests for the macro errors fail on toolchains newer than that.

This is changed to:

= note: this error originates in the macro `$crate::report` which comes from the expansion of the macro `bail` (in Nightly builds, run with -Z macro-backtrace for more info)

This is changed to:

= note: this error originates in the macro `$crate::report` which comes from the expansion of the macro `ensure` (in Nightly builds, run with -Z macro-backtrace for more info)

The which comes from the expansion of the macro `...` part is new.

Related Problem

Let's say I have a library crate that uses error-stack for all its errors, and a pre-existing user-facing program that wants to use this library but doesn't want to do a big-bang migration of all its own error handling to use error-stack and may not ever care to - let's say it just uses Box<dyn Error> for all its errors.

Integrating the library's error types into the application is currently very clumsy and weird, requiring us to either pull the Contexts out of the Reports manually, stringify the errors, or some other tedious and undesirable pattern.

Proposed Solution

Other error handling libraries provide some conversion options for integrating with std Error that would solve this issue for error-stack. By way of example, eyre has the following:

• impl AsRef<dyn Error + 'static> for Report
• impl Deref<Target = dyn Error + Send + Sync + 'static> for Report
• impl From<Report> for Box<dyn Error + 'static>

Alternatives

One possible alternative is implementing Error directly on Report. I can't tell whether this is deliberately being avoided, but neither eyre or anyhow do this for their error types so I assume there's a good reason not to choose this option.

Additional context

No response

Describe the bug

Hi,
First of all, thanks for the great work, error-stack has helped me for proper error handling with attachable information like whether an error is retryable.

To the point: I am trying to output errors with a changed context in them, but it only prints out the latest context.

To reproduce

// 1. I have an error of type ErrorA in a result.
// 2. I call `result.into_report().change_context(ErrorB::Something)?`.
// 3. (I attach information like `result.attach(Retryable::Yes)`.)
// 4. (I match on the report in the result and call `err.downcast_ref::<Retryable>`.)
// 5. I print the error, but it only gives `ErrorB::Something`

use error_stack::{bail, Report, ResultExt};
use thiserror::Error;

fn main() {
    if let Err(err) = changing_function() {
        println!("Error: {err}");
    }
    println!("Done");
}

fn changing_function() -> Result<(), Report<ErrorB>> {
    erroring_function().change_context(ErrorB::Variant)?;
    Ok(())
}

fn erroring_function() -> Result<(), Report<ErrorA>> {
    bail!(ErrorA::Variant);
}

#[derive(Debug, Error)]
enum ErrorA {
    #[error("Error A")]
    Variant,
}

#[derive(Debug, Error)]
enum ErrorB {
    #[error("Error B")]
    Variant,
}

Expected behavior

From the implementation of Display, it looks like it iterates over the frames and prints out all. When I manually iterate over the frames and do a dbg! on them, I can also see there is another frame with a context that includes ErrorA. However, while printing, it is gone. I assume it somehow gets considered as attachment, even though it should not be right?

Rust compiler

rustc 1.65.0 (897e37553 2022-11-02)

Host

x86_64-unknown-linux-gnu

Target

stable-x86_64-unknown-linux-gnu

Version

v0.2.4

Features

default

Additional context

No response

Description coming soon

Blocked by #2278 / H-1

All prerequisites were met, and I verified that I have all the correct versions of git, node, yarn, docker, and docker-compose. I also verified that none of the required ports are in use. At the step: yarn external-services up --detach I'm met with the following error:

yarn external-services up --detach
yarn run v1.22.17
$ docker-compose --file external-services/docker-compose.yml up --detach
Traceback (most recent call last):
File "urllib3/connectionpool.py", line 677, in urlopen
File "urllib3/connectionpool.py", line 392, in _make_request
File "http/client.py", line 1277, in request
File "http/client.py", line 1323, in _send_request
File "http/client.py", line 1272, in endheaders
File "http/client.py", line 1032, in _send_output
File "http/client.py", line 972, in send
File "docker/transport/unixconn.py", line 43, in connect
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "requests/adapters.py", line 449, in send
File "urllib3/connectionpool.py", line 727, in urlopen
File "urllib3/util/retry.py", line 410, in increment
File "urllib3/packages/six.py", line 734, in reraise
File "urllib3/connectionpool.py", line 677, in urlopen
File "urllib3/connectionpool.py", line 392, in _make_request
File "http/client.py", line 1277, in request
File "http/client.py", line 1323, in _send_request
File "http/client.py", line 1272, in endheaders
File "http/client.py", line 1032, in _send_output
File "http/client.py", line 972, in send
File "docker/transport/unixconn.py", line 43, in connect
urllib3.exceptions.ProtocolError: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "docker/api/client.py", line 214, in _retrieve_server_version
File "docker/api/daemon.py", line 181, in version
File "docker/utils/decorators.py", line 46, in inner
File "docker/api/client.py", line 237, in _get
File "requests/sessions.py", line 543, in get
File "requests/sessions.py", line 530, in request
File "requests/sessions.py", line 643, in send
File "requests/adapters.py", line 498, in send
requests.exceptions.ConnectionError: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "docker-compose", line 3, in
File "compose/cli/main.py", line 81, in main
File "compose/cli/main.py", line 200, in perform_command
File "compose/cli/command.py", line 70, in project_from_options
File "compose/cli/command.py", line 153, in get_project
File "compose/cli/docker_client.py", line 43, in get_client
File "compose/cli/docker_client.py", line 170, in docker_client
File "docker/api/client.py", line 197, in init
File "docker/api/client.py", line 222, in _retrieve_server_version
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))
[11747] Failed to execute script docker-compose
error Command failed with exit code 255.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

We use blurhashes elsewhere on the hash.dev blog. A consistent approach should be taken here that integrates with the existing approach.

We have a "slide" component in use on https://hash.dev/blog/block-paved-path to load presentation slides on the left-side of a page, and accompanying copy on the right-side. Whereas our other images use blurhashes to gracefully load in, these slides do not appear at all until they have loaded in completely (and they seem to be loading slowly at the moment). This can be confusing.

_{From SyncLinear.com | H-4}

Is your feature request related to a problem? Please describe.

I am currently implementing #794. With the recent release of 1.63, I would like a clarification on the officially supported MSRV for error-stack 0.2.

This is expressed in two ways, which I'd consider blocking until a concrete ruling has been given.

1.63 stabilized explicit_generic_args_with_impl_trait, which is part of the current rework of the hook architecture.

https://github.com/indietyp/hash/blob/40e389247364eeac6cf955c60b8bbe9938da541e/packages/libs/error-stack/src/hook.rs#L54-L56

Another way would be that we would likely be able to drop the hooks feature if we set the MSRV to 1.63 and work with only std for hooks, as it currently brings in a new dependency once_cell, which we could fully replace by RwLock.

https://github.com/indietyp/hash/blob/40e389247364eeac6cf955c60b8bbe9938da541e/packages/libs/error-stack/src/hook.rs#L13-L18

The current hack that has been used to fix #873, could be rewritten to be more precise.

https://github.com/indietyp/hash/blob/40e389247364eeac6cf955c60b8bbe9938da541e/packages/libs/error-stack/src/report.rs#L246-L248

        let span_trace = if core::any::request_ref::<SpanTrace>(&provider)
            .filter(|span_trace| span_trace.status() == SpanTraceStatus::CAPTURED)
            .is_some()

(same with the Backtrace code)

This is because with the nightly version, after the stabilization of explicit_generic_args_with_impl_trait, the number of generics in request_ref was changed. We no longer need to employ the hackif we only support versions that have explicit_generic_args_with_impl_trait stabilized.

These are not necessarily deal breakers but could make the API more concise. To be able to implement them, an official MSRV is needed.

Describe the solution you'd like

README.md entry about the current MSRV and CI/CD tests for the MSRV.

Additional context

This has been discussed off GH with @TimDiekmann.

Describe the bug

During step 3 of the Getting Started process,

yarn install

did not complete successfully.

Logs:
...
node-gyp rebuild

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | win32 | x64
gyp info find Python using Python version 3.10.2 found at "C:\Users\geert\AppData\Local\Programs\Python\Python310\python.exe"
gyp ERR! find VS
gyp ERR! find VS msvs_version not set from command line or npm config
gyp ERR! find VS running in VS Command Prompt, installation path is:
gyp ERR! find VS "C:\Program Files\Microsoft Visual Studio\2022\Professional"
gyp ERR! find VS - will only use this version
gyp ERR! find VS unknown version "undefined" found at "C:\Program Files\Microsoft Visual Studio\2022\Professional"
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use
gyp ERR! find VS looking for Visual Studio 2015
gyp ERR! find VS - not found
gyp ERR! find VS not looking for VS2013 as it is only supported up to Node.js 8
gyp ERR! find VS
gyp ERR! find VS **************************************************************
gyp ERR! find VS You need to install the latest version of Visual Studio
gyp ERR! find VS including the "Desktop development with C++" workload.
gyp ERR! find VS For more information consult the documentation at:
gyp ERR! find VS https://github.com/nodejs/node-gyp#on-windows
gyp ERR! find VS **************************************************************
gyp ERR! find VS
gyp ERR! configure error
gyp ERR! stack Error: Could not find any Visual Studio installation to use
gyp ERR! stack at VisualStudioFinder.fail (C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\find-visualstudio.js:121:47)
gyp ERR! stack at C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\find-visualstudio.js:74:16
gyp ERR! stack at VisualStudioFinder.findVisualStudio2013 (C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\find-visualstudio.js:351:14)
gyp ERR! stack at C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\find-visualstudio.js:70:14
gyp ERR! stack at C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\find-visualstudio.js:372:16
gyp ERR! stack at C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\util.js:54:7
gyp ERR! stack at C:\hash\hash\node_modules\re2\node_modules\node-gyp\lib\util.js:33:16
gyp ERR! stack at ChildProcess.exithandler (node:child_process:420:5)
gyp ERR! stack at ChildProcess.emit (node:events:513:28)
gyp ERR! stack at maybeClose (node:internal/child_process:1091:16)
gyp ERR! stack at ChildProcess._handle.onexit (node:internal/child_process:302:5)
gyp ERR! System Windows_NT 10.0.22621
gyp ERR! command "C:\Program Files\nodejs\node.exe" "C:\hash\hash\node_modules\re2\node_modules\node-gyp\bin\node-gyp.js" "rebuild"
gyp ERR! cwd C:\hash\hash\node_modules\re2
gyp ERR! node -v v18.12.1
gyp ERR! node-gyp -v v8.3.0
gyp ERR! not ok
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^

To reproduce

Follow 'Getting started' procedure.

Expected behavior

No response

Device

No response

Operating system

Windows 11

Browser

No response

Additional context

• I validated dependency versions.
• I do have workload "Desktop development with C++" installed.
• I tried to set 'msvs_version', but got the same results.

[email protected] is being used. Version [email protected] seems to have better support for Windows 11 SDK?
How to update node-gyp version?

Is your feature request related to a problem? Please describe.

We should add a section in the crate-level documentation on how to write attachments and context messages.

Describe the solution you'd like

We probably want to suggest using non-capitalized messages, this aligns well with the Rust API guidelines.

Describe alternatives you've considered

Capitalizing attachments may be more readable, however, it's a common practice to put errors in context and errors should not be capitalized. This results in inconsistency.

Is your feature request related to a problem?

When using TryStream and its ecosystem it's not possible to convert the underlying error into a Report. Considering the following code from 062ca90:

row_stream
    .into_report()
    .change_context(QueryError)
    .try_filter_map(|row| async move {
        ...
    })

instead of

row_stream
    .map(IntoReport::into_report)
    .change_context(QueryError)
    .try_filter_map(|row| async move {
        ...
    })

Describe the solution you'd like

This can be solved in two ways:

• Implement IntoReport for TryStream, but this would require another adaptor, e.g. IntoTryStreamReport
• Remove IntoReport and make it implicit when calling change_context or attach(_printable)

I'd probably go with the second route for two reasons:

• Adding another adaptor makes usage of the library harder. To improve this, a prelude module could be introduced, which is exporting Trait as _, but generally, preludes make it hard to reason about what is going on in a library. Without a prelude, this always requires a bunch of traits to be imported into the file. Just calling .change_context(...) is very straightforward.
• IntoReport was introduced to avoid side effects when constructing Report<E> from E, e.g. capturing of a backtrace or span trace. However, this implies that the code is already on the non-happy path, so things went wrong anyway. In each case, Box::new is called (it's required for creating a Frame), so I don't know if this argument is good anyway.

I consider this as a blocker for error-stack v0.2 as the IntoReport type already changed since v0.1.1 and the StreamExt adaptor was introduced since then.

Asana Task (internal)

Describe the bug

In your example

Error: experiment error: could not run experiment
├╴src/main.rs:74:18
├╴unable to set up experiments
│
├─▶ invalid experiment description
│   ├╴src/main.rs:44:10
│   ╰╴experiment 2 could not be parsed

I clicked on src/main.rs:44:10 but the IDE has problems in interpreting it and prompts that it does not find the location:

Probably it's due to the fact, that there is no space before src like ├╴ src/main.rs:44:10

To reproduce

Click on location ├╴src/main.rs:44:10 in error report.

Expected behavior

Editor jumps to the correct position in the source code.
Probably no so compact nice, but putting a space behind ├╴ or ╰╴ would help.

Discussed in #1866

use std::fmt::Display;

use error_stack::{Context, Report};

#[derive(Debug)]
pub struct DbError;

impl Display for DbError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "database error")
    }
}

impl Context for DbError {}

#[derive(Debug, thiserror::Error)]
pub enum Error {
    #[error(transparent)]
    DbError(Report<DbError>),
}

fn main() {}

error[E0599]: the method `as_dyn_error` exists for reference `&error_stack::Report<DbError>`, but its trait bounds were not satisfied
   --> src/main.rs:16:17
    |
16  | #[derive(Debug, thiserror::Error)]
    |                 ^^^^^^^^^^^^^^^^ method cannot be called on `&error_stack::Report<DbError>` due to unsatisfied trait bounds
    |
   ::: /Users/mkatychev/.cargo/registry/src/github.com-1ecc6299db9ec823/error-stack-0.2.4/src/report.rs:195:1
    |
195 | pub struct Report<C> {
    | --------------------
    | |
    | doesn't satisfy `error_stack::Report<DbError>: AsDynError`
    | doesn't satisfy `error_stack::Report<DbError>: std::error::Error`
    |
    = note: the following trait bounds were not satisfied:
            `error_stack::Report<DbError>: std::error::Error`
            which is required by `error_stack::Report<DbError>: AsDynError`
            `&error_stack::Report<DbError>: std::error::Error`
            which is required by `&error_stack::Report<DbError>: AsDynError`
    = note: this error originates in the derive macro `thiserror::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0599`.
error: could not compile `play` due to previous error

#[derive(Debug, thiserror::Error)]
pub enum Error<C> {
    #[error(transparent)]
    DbError(Report<C>),
}

I have been checking out error-stack lately, and it seems very promising, great work! For my specific usecase I would want report multiple errors at once, while not natively supported by the std::error::Error trait, crates like miette have the concept of related errors.

From my investigation into the library error-stack doesn't currently support this feature, is this correct? Are there any plans for supporting such a thing in the future? or would you be open for a PR implementing something like this? I think something like this would be a great addition to the library!

What I'd love to have is a DAG like the diagram below:

flowchart BT
  err1{{std::io::Error}}
  err2{{std::io::Error}}
  err3{{crate1::Error}}

  ctx1[crate2::Context]
  ctx2[crate3::Context]
  ctx3[crate4::Context]
  ctx4[crate2::Context2]
  ctx5[crate3::Context2]
 
  err1 --> ctx1
  ctx1 --> ctx2
  err2 --> ctx2
  ctx2 --> ctx3
  err3 --> ctx4
  ctx4 --> ctx5
  ctx5 --> ctx3

So I'm attempting to use the latest error-stack with the latest nightly (currently 2022-08-04), and I'm getting this error when running cargo check --workspace

discord-chess on  feature/start-game is 📦 v0.1.0 via 🦀 v1.64.0-nightly via ❄️  impure (nix-shell)
❯ cargo check --workspace
    Checking error-stack v0.1.1 (https://github.com/hashintel/hash#45598cd1)
   Compiling mysql_common v0.28.2
    Checking tokio-rustls v0.23.4
   Compiling darling v0.13.4
    Checking tracing-futures v0.2.5
    Checking serde_json v1.0.83
    Checking futures v0.3.21
   Compiling pest_meta v2.2.1
    Checking tokio-native-tls v0.3.0 (https://github.com/pimeys/tls?branch=vendored-openssl#6d0e6fc7)
    Checking frunk v0.4.0
    Checking async-native-tls v0.4.0
    Checking diagnostics v0.1.0 (https://github.com/Brendonovich/prisma-engines?rev=5d34c9a567aaec4065a48d8cf6c2ee885e6ca281#5d34c9a5)
    Checking rusqlite v0.25.4
    Checking trust-dns-proto v0.21.2
    Checking h2 v0.3.13
    Checking tokio-native-tls v0.3.0
    Checking graphql-parser v0.3.0 (https://github.com/prisma/graphql-parser?rev=6a3f58bd879065588e710cb02b5bd30c1ce182c3#6a3f58bd)
    Checking tungstenite v0.17.3
   Compiling darling v0.14.1
    Checking cuid v0.1.0 (https://github.com/prisma/cuid-rust?rev=4ffb2e47c772af62fed3ddc92bb7fc444d19e159#4ffb2e47)
error[E0599]: no method named `backtrace` found for reference `&'a C` in the current scope
   --> /home/tntman/.cargo/git/checkouts/hash-b57e41be1ab6aef3/45598cd/packages/libs/error-stack/src/context.rs:107:39
    |
107 |         if let Some(backtrace) = self.backtrace() {
    |                                       ^^^^^^^^^ method not found in `&'a C`

   Compiling serde_with_macros v1.5.2
    Checking opentelemetry v0.16.0
For more information about this error, try `rustc --explain E0599`.
error: could not compile `error-stack` due to previous error
warning: build failed, waiting for other jobs to finish...

the repo is avalible at https://github.com/Suyashtnt/discord-chess-2/tree/feature/start-game, error stack is mainly being used in the commands and events crates

Describe the bug
Trying to build on latest nightly fails with the following error:

error[E0599]: no method named `backtrace` found for reference `&'a C` in the current scope
   --> /home/joseprogdp/.cargo/registry/src/github.com-1ecc6299db9ec823/error-stack-0.1.1/src/context.rs:108:39
    |
108 |         if let Some(backtrace) = self.backtrace() {
    |                                       ^^^^^^^^^ method not found in `&'a C`

To reproduce
Update to the latest nightly toolchain with rustup update or switch to it with rustup default nightly. After this, create a new cargo project and add error-stack as a dependency. Run cargo r or carbo b and observe the error.

Expected behavior
I expected error-stack to build.

Desktop (please complete the following information):

• OS: Windows 11
• rustc: 1.65.0-nightly (9c20b2a8c 2022-08-17)
• target: wasm32-unknown-unknown
• Version: latest
• Features: default

This dashboard has moved. Please see #3037

Feature

I think a great feature to add to the error-stack library would be a method on the report that lets you change the exit code.

Motivation

Depending on the type of application you are writing, an exit code can give a lot of information to the user.

By default, Result types can be returned from the main function and provide an exit code. However, all error-stack errors currently return an exit code of 1.

Implementation

A method, exit_code(&self, code: i32) or could be named attach_exit_code(...) for symmetry, could be added to the Report struct, or maybe the ResultExt trait might be a better place for it.

The following steps would be to use Rust's Termination trait. This method is already implemented on the Result type by default, and error-stack conveniently exposes a Result alias that's more specific. So I believe just adding this trait implementation over the Report type would work, and by default, it could return an exit code of 1 as it currently does. This default behavior also aligns with Rust's errors.

If the idea seems beneficial to the crate, I'd be willing to take a stab at this and open a PR.

With error-stack v0.1 our MSRV is 1.61, but with v0.2 it will be bumped to 1.63. When looking at the documentation it's not possible to determine the MSRV for the current version. Looking at the repository is misleading because it only captures the most recent MSRV.

Asana Task (internal)

I think this would be nice to have vs. ok_or_else() + deliberate Report::new()

Due to rust-lang/rust#96024 (comment) (rust-lang/rust#98912) the following no longer compiles:

It seems that something to do with change_context's signature breaks the intellisense of CLion. It's usually pretty good at inferring the types of variables (although it doesn't always match up with the compilers abilities/decisions).

When we use change_context though, the type is 'unknown' and this breaks things like "go to method", which can actually be quite annoying.

I suspect this is a bug on Jetbrain's end and we might want to investigate and open a ticket with them, but we should also see if there's something we can do to make the IDE more happy.

Example with change_context:

Example without (note the type annotation):

Describe the bug

I use solarized-dark color scheme in my terminals and noticed after upgrading that I can not see some parts of the output (until I highlight it).

To reproduce

No response

Expected behavior

Would be better if I was able to see colors. I think I've seen that color output is behind an optional cargo feature, so I'm going to try disabling them, and that's good enough workaround for me, I think.

BTW. Recently clap has made a decision to abandon colors and rely only on underline, bold font, etc. to make the output readable.

The reasoning was that not only it's hard to find color scheme that works for everyone, but also - businesses and teams have sometimes their own branding etc. and error colors might get in a way.

Rust compiler

No response

Host

No response

Target

No response

Version

No response

Features

No response

Additional context

No response

Using Code Server as my IDE (in-browser and Monaco-based, like hCore), I constantly use the tab operations like Close All. Please see the image below for more examples. Without that option in the hCore editor pane and without documented shortcuts https://docs.hash.ai/core/extra/shortcuts, I'm finding some editor pane operation to be a bit cumbersome/slow. For example, closing 10 tabs appears to require clicking each of the "X" close buttons. I'm opening this issue as a feature request - whatever the implementation, improved user experience around multi-tab operations would be appreciated.

Describe the bug

The link in the README.md is a local path, so it is not rendered on crates.io

Version

v0.2.0

External python libraries that are supported in Core fail to run in cloud. The list includes:

• networkx
• scipy
• pandas
• scikit-learn

A fix is being implemented that will restore functionality.

Describe the bug

Running into this issue when cargo build is compiling nano v0.0.0 and as a result when cargo run despite that I've already activated nightly toolchain.

Not sure what's going on, I tried all the tricks in the book including rustup default nightly. Still not working....

To reproduce

1. run cargo build under engine directory
2. run cargo run under same directory

Link to HASH Core

No response

Expected behavior

I guess it's just supposed to run?

Rust compiler

1.68.2

Host

aarch64-apple-darwin

Target

nightly-2022-08-08-aarch64-apple-darwin

Version

3.8.10

Additional context

No response

Description coming soon, and link to GitStart-shared Figma file.

_{From SyncLinear.com | H-7}

We want to add all blocks marked as maintained from our repo to the Storybook.

Blocked by #2278 / H-1

This dashboard has moved. Please see #3037

Describe the bug

Error: Setup required.
├╴at src/run.rs:101:10
╰╴ABC
   
   DEF

It looks like the space after ╰╴ was removed which means there are one too many spaces in the rest of the attachment. Maybe removing the space after each line is a mistake? I kinda like the old one better. Old:

Error: Setup required.
├╴ src/run.rs:101:10
╰╴ ABC
   
   DEF

To reproduce

Attach a multi-paragraph string.

Describe the bug

I tried to build Hash from scratch using WSL, following the Getting Started steps.

To reproduce

Using Ubuntu 20.04.5 LTS (up to date)

Checked versions of Git, Node, Yarn, Docker

• creating folder 'hashintel'
• git clone https://github.com/hashintel/hash.git
• cd into folder 'hash'
• yarn install

Expected behavior

Expected succesful result, but install ends with:

[4/4] Building fresh packages...
[-/18] ⠠ waiting...
[-/18] ⠠ waiting...
[14/18] ⠠ @sentry/cli
[-/18] ⠐ waiting...
error /mnt/c/hashintel/hash/node_modules/@sentry/cli: Command failed.
Exit code: 1
Command: node ./scripts/install.js
Arguments:
Directory: /mnt/c/hashintel/hash/node_modules/@sentry/cli
Output:
info sentry-cli Downloading from https://downloads.sentry-cdn.com/sentry-cli/1.74.6/sentry-cli-Linux-x86_64

Device

No response

Operating system

Ubuntu 20.04.5 LTS (up to date)

Browser

No response

Additional context

No response