Fix - use flags api for trace flags#478
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates SQL comment query tagging to generate the W3C traceparent trace-flags field from the active OpenTelemetry span context rather than hardcoding "01", ensuring all valid flag bit combinations are propagated accurately.
Changes:
- Updated
TraceContextInjectorto useSpanContext.getTraceFlags().asHex()when building the injectedtraceparent. - Updated the unit test to stub
SpanContext.getTraceFlags()for the mocked span context.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| instrumentation/instrumentation-shared/src/main/java/com/solarwinds/opentelemetry/instrumentation/TraceContextInjector.java | Uses OpenTelemetry’s TraceFlags API when constructing the traceparent string for SQL comment injection. |
| instrumentation/instrumentation-shared/src/test/java/com/solarwinds/opentelemetry/instrumentation/TraceContextInjectorTest.java | Updates mocking to provide trace flags so the new implementation path is exercised. |
Comments suppressed due to low confidence (1)
instrumentation/instrumentation-shared/src/test/java/com/solarwinds/opentelemetry/instrumentation/TraceContextInjectorTest.java:63
- The expected value still hardcodes the trace-flags as
01. Since the production code now usesspanContext.getTraceFlags().asHex(), consider building the expected string usingTraceFlags.getSampled().asHex()so the test stays aligned with the implementation and avoids duplicating the literal.
String actual = TraceContextInjector.inject(Context.current(), sql);
String expected = String.format("/*traceparent='00-%s-%s-01'*/ %s", traceId, spanId, sql);
assertEquals(expected, actual);
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replace the hardcoded
"01"trace-flags value in thetraceparentSQL comment injection with the OpenTelemetrySpanContext.getTraceFlags().asHex()API to correctly propagate all valid flag values.Details
The
TraceContextInjectorbuilds a W3Ctraceparentheader and injects it as a SQL comment for query tagging. Previously, the trace-flags field was hardcoded to"01". This is incorrect because trace flags today can be00,01,02, or03. TheisSampled()guard ensures only sampled spans reach this code, but a sampled span can have flags01or03— the old hardcoded value would silently drop the second bit.Using
getTraceFlags().asHex()ensures the injectedtraceparentaccurately reflects the span's actual flags.The test is updated to stub
getTraceFlags()on the mockedSpanContext, returningTraceFlags.getSampled().Test services data