using `Span::record` leads to multiple instances

[rugged robin]

I am using trying to update a value in a span. I found https://docs.rs/tracing/latest/tracing/struct.Span.html#method.record where it says: However, it may also be used to record a new value for a field whose value was already recorded (with a example is_okay).

I basically want to do the same thing:
I have a function where I iterate over some steps. I want to log the name of the step that is processed. Instead of creating a new sub-span under my parent-span with the respective step name. I just want to modify step in parent-span directly.

I expect the following logs:

parent{trace_id=1, step=""} Start executing
parent{trace_id=1, step="stepA"} going to the ice cream shop
parent{trace_id=1, step="stepB"} buying ice cream
parent{trace_id=1, step="stepC"} delicious

however, I get:

parent{trace_id=1, step=""} Start executing
parent{trace_id=1, step="stepA"} going to the ice cream shop
parent{trace_id=1, step="stepA", step="stepB"} buying ice cream
parent{trace_id=1, step="stepA", step="stepB", step="stepC"} delicious

Isn't that in contrast to the docu, which says that the value is updated ? Instead I end with multiple step.

The span is created like:

let future = /* ... */;   
let future = future.instrument(tracing::span!(
    Level::INFO,
    "reconcile",
    id,
    step = tracing::field::Empty
));
let result = future.await;

and updated like:

tracing::Span::current().record("step", tracing::field::debug(&step_name));

full code can be found here

[craggy heath]

I'm afraid this is a known issue that isn't super easy to fix (efficiently) and so it's been left like that.

Here's the canonical ticket: https://github.com/tokio-rs/tracing/issues/1372

So far, no one has spent the time on fixing it properly.

I have some ideas about how to fix this.

Instead of storing a single string for all span fields, we should store a serialized value string per field and then perform a hopefully not too expensive final serialization each time we need to output all the span fields.

So if you'd like to have a go, you're more than welcome.

[rugged robin]

thanks for the quick response. I think i now at least understand the issue.

So the issue is more in tracing-subscriber crate which is responsible for actually storing the data ?

I could have a look, maybe I can fix it (or at least write a warning to the documentation)

[rugged robin]

I am wondering if this will need a semver change to 0.4 though :/

[rugged robin]

I am also wondering, as soons as we introduce something like:

 fields: Vec<Field, String>

we have another problem, we suddenly need to format a single Field however our function is used to format https://docs.rs/tracing-subscriber/latest/tracing_subscriber/fmt/trait.FormatFields.html#tymethod.format_fields .

Honestly, as an outsider I am very overwhelmed by looking at the structures here, all the cross-references and for now i just tried to avoid the lifetimes :/

[craggy heath]

Yeah, we would basically have to abuse the FormatFields trait and pass the fields one by one.

Otherwise, yeah. A breaking change.

However, I wouldn't release a breaking change to tracing-subscriber just for the fmt layer, since that's actually a minor part of the crate's API surface (despite being what most people use).

The reason is that the entire fmt Layer could actually live in a separate crate, it only uses the public API of other parts of the same crate (in fact, I believe it was once in its own crate).