You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theTimings
struct and haveFmtSubscriber
(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 theCollector
before the consumingSubscribe
. 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 ason_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 - differentSubscribe
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 respectiveSubscribe
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.The text was updated successfully, but these errors were encountered: