Mapping from one context to another

[chrs-b]

I have a codebase where errors are stacked 😅 in different modules:

---

// job module
fn do_something() -> Result<(), Report<JobError>> {
  let database = Database::new();
  database.read_something(...).change_context(JobError::Internal)?;
  ...
}

---

// database module
impl Database {
  fn read_something(...) -> Result<(), Report<DBError>> {
    sqlx::query(...).map_err(|e| Err(Report::new(DBError::from(e)))?;
    ...
  }
}

Now, I would like to create the higher level JobError depending on lower level DBError and map all or some of the lower lever errs to related ones on higher level.

Is there a way to add a context with access to the lower level context that can be function chained line .change_context()?

I know I can match on the intermediate Result<Report>, but that would break chaining.

Ideally, something like

// job module
fn do_something() -> Result<(), Report<JobError>> {
  database.read_something(...).change_mapped_context(|context| JobError::from(context))?;
  ...
}

---

N.b. Don't take this too seriously:

I think change_context is a bit of a misnomer, as it adds or "stacks" a context instead of changing the current context.
Why not call it stack or stack_context instead? After all the crate's name is "error stack" 😄

[TimDiekmann]

Hey @chrs-b, thanks for bringing this up!

change_mapped_context

I can see the appeal, but I think this would actually go against a design choice in error-stack that's worth explaining.

change_context is designed so the new context comes from what the caller knows, not from what the lower error contains. The job layer knows "I was processing a job", the database layer knows "a query failed" — these are independent facts:

database.read_something(...)
    .change_context(JobError::ReadFailed)?;

Deriving JobError from DBError via something like change_mapped_context(|ctx| JobError::from(ctx)) is really a re-categorization, not adding context. If JobError can be mechanically derived from DBError, that's usually a sign the two types are either redundant, or the job layer is leaking database details into its error type.

If you do need different behavior depending on the underlying error — say NotFound → retry, ConnectionFailed → abort — that's a deliberate architectural coupling, and a match makes that decision visible:

match database.read_something(...) {
    Ok(v) => Ok(v),
    Err(report) => {
        let job_err = match report.current_context() {
            DBError::NotFound => JobError::NotFound,
            _ => JobError::Internal,
        };
        Err(report.change_context(job_err))
    }
}

That match isn't boilerplate — it documents a conscious decision about how two layers couple together. Making it chainable would make it too easy to just mechanically re-label errors up the stack without actually adding information.

Note on your example

sqlx::query(...).map_err(|e| Err(Report::new(DBError::from(e))))?;

Small thing: map_err expects the error value directly, so the Err(...) wrapper shouldn't be there. But this is also a good example of where change_context does exactly what you need:

sqlx::query(...).change_context(DBError::QueryFailed)?;

The sqlx::Error stays in the Report as a lower frame, you don't lose it. DBError::QueryFailed says what your layer knows: "query failed". No need to manually convert sqlx errors into DBError variants — same principle as above.

On the naming

Haha, yes 😄 change_context can be confusing since the old context isn't actually removed. The name refers to changing the type parameter of Report<C> → Report<T>, so current_context() returns the new type afterwards. The old context becomes historical record, only reachable via downcast_ref. stack_context would imply both remain equally accessible, which isn't quite right either. But I get the confusion — it's a tricky name to get right.

---

Let me know if that reasoning makes sense or if you have a use case where change_context alone doesn't quite work — always happy to dig into concrete examples.

[chrs-b]

Thanks for the quick reply!

In my example I need some (not all) of the underlying errs mapped to higher level and several lower errors might result in a higher one.
DBError is an enum with e.g. DBError::NotFound and others, mapped from sqlx::Error. The JobError has different semantics and a different set of errors, which in most cases can be easily mapped from DBError.

I can see your point, but it would require to "shadow" all lower errors with higher level ones. For my use case it would be great to chain it up, as the match and map is quite lengthy. Anyways, thanks for your insight, will code around it.

Overall a great crate, I use it everywhere in my new project and error msgs are a dream come true. Thanks for sharing all your hard work!