rust-lang / rust-lang/log

Consider bringing back `kv` `Value` downcasting

Open
#641 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

structured-logging
Dominant language
Rust
Stars
2.5k
Forks
289
Avg merge
55m
Merged PRs (30d)
1

Description

While working on a Rust application, I became interested in downcasting a Value associated with a log record when using the kv feature of the log crate. To my surprise, I discovered that this capability was removed when the kv feature was stabilized:

https://github.com/rust-lang/log/blob/96dbf58ec05e844ec55aa2282f32f612372fbced/src/kv/value.rs#L1100-L1107

In my view, there are compelling use cases for downcasting log record Values: that enables different software components to process them in a loosely coupled way, effectively repurposing log Records as a versatile, typed message-passing mechanism.

For instance, imagine integrating an existing codebase that logs anyhow::Errors with sentry reporting, with the requirement that generated Sentry events should include the error backtrace. With Value downcasting, this could be achieved by doing this at the logging site:

log::error!(error = anyhow_error; "Something went wrong");

And then, to emit Sentry events from these log records with the error backtrace, one could simply pass a custom mapper function to a SentryLogger that retrieves the error value from the record, downcasts it to an anyhow::Error, calls the backtrace() method on it, and attaches that backtrace to the Sentry event.

Without record Value downcasting, there isn’t an elegant solution for the scenario above. Approaches like using custom serde serializers or establishing an additional communication channel between log sites and logger implementations may work in certain cases, but they are far from ideal.

On a different codebase, but this time proof of concept and open-source, I've also found downcasting useful for passing along typed status update messages that get formatted in the way most appropriate for the target environment by just switching between custom logger implementations.

I've scoured the repository for any issues or commits explaining the rationale for removing Value downcasting but couldn’t find anything beyond a suggestion to file an issue if this is a feature "you rely on". Therefore, I’m opening this issue to understand the context of its removal and to inquire if adding it back is feasible. Are there any drawbacks or implementation constraints I might be overlooking?

Edit: after giving it more thought, the Sentry integration example above perhaps could be solved by using the downcast method available on dyn Error, as anyhow::Errors implement the Error trait... But that's still not helpful for the different codebase example, and not applicable when introspecting Values other than Errors is desired.

Edit 2: nevermind the edit above, anyhow::Error does not implement std::error::Error and thus cannot be downcasted like that.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading src/kv/value.rs around lines 1100-1107, where Value downcasting was removed, and review the linked Sentry logger mapper and PackSquash example for usage requirements. Done means establishing whether downcasting can be safely restored and documenting the relevant implementation constraints or an agreed direction in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.