move ID rewriting to the client side #240
Labels
Comments
hawkw
added a commit
that referenced
this issue
Dec 28, 2021
Currently, `console-subscriber` contains a bunch of machinery for rewriting non-sequential `span::Id`s from `tracing` to sequential IDs (see #75). Upon thinking about this for a bit, I don't actually understand why this has to be done on the instrumentation-side. This seems like extra work that's currently done in the instrumented application, when it really doesn't have to be. Instead, the client should be responsible for rewriting `tracing` IDs to pretty, sequential user-facing IDs. This would have a few advantages: - it moves some work out of the application, which is always good - if data is being emitted through an implementation other than `console-subscriber`, we will *still* get nicely ordered ids - this also makes some of the stuff i'm working on in #238 easier This branch removes ID rewriting from `console-subscriber`, and adds it to the `console` CLI's `state` module. Closes #240 Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently,
console-subscribercontains a bunch of machinery for rewriting non-sequentialspan::Ids fromtracingto sequential IDs (see #75). Upon thinking about this for a bit, I don't actually understand why this has to be done on the instrumentation-side. This seems like extra work that's currently done in the instrumented application, when it really doesn't have to be.Instead, the client should be responsible for rewriting
tracingIDs to pretty, sequential user-facing IDs. This would have a few advantages:console-subscriber, we will still get nicely ordered idsThe text was updated successfully, but these errors were encountered: