Closed mhlidd closed 1 week ago
Baseline | Candidate | |
---|---|---|
baseline_or_candidate | baseline | candidate |
git_branch | master | mhlidd/tracecontext_inconsistency |
git_commit_date | 1730731065 | 1730738630 |
git_commit_sha | 6eac0b8465 | e3eb2e0459 |
release_version | 1.42.0-SNAPSHOT~6eac0b8465 | 1.43.0-SNAPSHOT~e3eb2e0459 |
Found 0 performance improvements and 0 performance regressions! Performance is the same for 53 metrics, 10 unstable metrics.
Baseline | Candidate | |
---|---|---|
baseline_or_candidate | baseline | candidate |
end_time | 2024-11-04T16:56:45 | 2024-11-04T17:05:52 |
git_branch | master | mhlidd/tracecontext_inconsistency |
git_commit_date | 1730731065 | 1730738630 |
git_commit_sha | 6eac0b8465 | e3eb2e0459 |
release_version | 1.42.0-SNAPSHOT~6eac0b8465 | 1.43.0-SNAPSHOT~e3eb2e0459 |
start_time | 2024-11-04T16:56:28 | 2024-11-04T17:05:35 |
Found 0 performance improvements and 0 performance regressions! Performance is the same for 7 metrics, 21 unstable metrics.
Baseline | Candidate | |
---|---|---|
baseline_or_candidate | baseline | candidate |
git_branch | master | mhlidd/tracecontext_inconsistency |
git_commit_date | 1730731065 | 1730738630 |
git_commit_sha | 6eac0b8465 | e3eb2e0459 |
release_version | 1.42.0-SNAPSHOT~6eac0b8465 | 1.43.0-SNAPSHOT~e3eb2e0459 |
Found 0 performance improvements and 0 performance regressions! Performance is the same for 12 metrics, 0 unstable metrics.
I’m here if you would like to talk about it. Basically, trace context flags are a set a flags, encoding using bit masks on 1 byte type. There is currently only one flag supported, called sampled.
So, there is no such things as set the sampling flag to 0, it’s either the sampled flag is set, or the sampled flag is not set. Settings the sampled flag will toggle the first bit of the byte to 1. Not settings the sampled flag will leave the byte to 0.
I think the important distinction to be made here is that there is a difference between not sampling and sampling unset, since the DD agent may update the sampling state after the span is created if the sampling is unset. Thus, it would be nice to be able to differentiate whether a span is not sampled vs sampling unset. If both are set to 0, there is no way to differentiate the two in the backend, which is also the reason that the bit-shifting was important for v04 encodings. This isn't a feature that is critical to this task, but is more of a nice to have.
I think the important distinction to be made here is that there is a difference between not sampling and sampling unset, since the DD agent may update the sampling state after the span is created if the sampling is unset. Thus, it would be nice to be able to differentiate whether a span is not sampled vs sampling unset.
What you are describing is the dropped
decision from the tracer. But such flag don't exist in tracecontext state, only sampled
exist.
If both are set to 0, there is no way to differentiate the two in the backend, which is also the reason that the bit-shifting was important for v04 encodings. This isn't a feature that is critical to this task, but is more of a nice to have.
The v0.4 protocol workaround should not impact the JSON encoding. If they ever come up with a drop flag, we will implement it :)
What Does This Do
Updates the keys in the Span Link creation to include the
attributes
field and to only includetracestate
when the propagation style istracecontext
. Additionally, wrote a unit test to verify the creation of Span Links when spans passed down through header tags are "invalid" due to differing trace_ids.Motivation
Currently the implementation of how Span Links are used when DD receives invalid traces are not consistent among libraries. This PR focuses on making the Java library's implementation of Span Links consistent with the following RFC.
Additional Notes
The way that the Java library is sending the
traceFlags
field is unclear, as there is no real way to differentiate whether a sampling flag is unset, or manually set to 0.Contributor Checklist
type:
and (comp:
orinst:
) labels in addition to any usefull labelsclose
,fix
or any linking keywords when referencing an issue.Use
solves
instead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]