-
Notifications
You must be signed in to change notification settings - Fork 847
Description
Feature Request
Crates
tracing-subscriber
Motivation
The timings shouldn't be tracked by the formatting subscribe. It's implementation was probably also copied when tracing-opentelemetry was created and now there are two slightly different implementations doing the same thing.
This seems like something a single layer in the subscriber should be doing and then the other layers (such as fmt and otel) can simply load the extension and use the value if needed.
Proposal
Extract the timings implementation as its own Subscribe, publicly expose the Timings struct and have FmtSubscriber (and eventually OpenTelemetry) use that.
The drawback is that now everything works out of the box while with this change, timings can only work if the Subscribe for timings is added to the Collector before the consuming Subscribe. Otherwise the extension may be missing or it may contain outdated information.
This could be fixed by having a way to register other Subscribe-like functionality in methods such as on_register_collector but that's currently impossible as far as I see. I do think that's something that could be useful in other areas as well - different Subscribe implementations reusing and registering required functionality. I'd like to know opinions on this, but I guess that if there is no opposition, this should maybe have its own issue.
Alternatives
Have all the implementations call the timings Subscribe methods directly in their respective Subscribe methods. That would at least deduplicate the code but the timings would still be measured twice unless they would somehow synchronize about who should do it.