-
Notifications
You must be signed in to change notification settings - Fork 214
Add traceStateValue parameter to DistributedTracingData.TryDeserializ… #2607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
💚 CLA has been signed |
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
👋 @otemnov Thanks a lot for your contribution! It may take some time before we review a PR, so even if you don’t see activity for some time, it does not mean that we have forgotten about it. Every once in a while we go through a process of prioritization, after which we are focussing on the tasks that were planned for the upcoming milestone. The prioritization status is typically reflected through the PR labels. It could be pending triage, a candidate for a future milestone, or have a target milestone set to it. |
Signed |
Thanks, @otemnov. This looks reasonable, and we should add this. I'd prefer to add a new method rather than amend the existing one. The existing methods are badly named, so I think we could opt to add a better-named factory method for this scenario. Would you mind tweaking the PR to add a method with this signature? We'll leave the original method for backwards compatibility of the existing functionality.
|
@stevejgordon thanks!
|
…eFromString method
We pass the 'traceparent' value in our asynchronous message communication.
We follow the instructions at https://www.elastic.co/guide/en/apm/get-started/7.10/distributed-tracing.html#_manual_distributed_tracing.
However, it is not possible to restore the 'tracestate' as it is for the Go agent implementation.
In pair 'restart_external' TraceContinuationStrategy, it is not possible to search the logs across services using the original traceid, as each message handling generates anew traceid due to the absence of a tracestate.
The PR suggests a possible solution.