What happened?
There is a critical bug in the v2 Elasticsearch storage backend reader where 64-bit Trace IDs are incorrectly padded when converted to OpenTelemetry pcommon.TraceID types. This results in the complete corruption of the Trace ID.
In internal/storage/v2/elasticsearch/tracestore/ids.go, the convertTraceIDFromDB function translates a DB trace ID (a hex-encoded string) into a 16-byte OpenTelemetry pcommon.TraceID.
func convertTraceIDFromDB(dbTraceId dbmodel.TraceID) (pcommon.TraceID, error) {
var traceId [16]byte
traceBytes, err := hex.DecodeString(string(dbTraceId))
if err != nil {
return pcommon.TraceID{}, err
}
copy(traceId[:], traceBytes) // BUG: Left-aligns the bytes
return traceId, nil
}
### Steps to reproduce
### **Steps to reproduce**
```markdown
1. Configure Jaeger with the `v2` Elasticsearch storage backend.
2. Query a trace that originally had a 64-bit Trace ID (16 hex characters).
3. Observe that the returned trace data has a corrupted 128-bit Trace ID where the 64-bit value is shifted to the left and padded with zeros on the right (e.g., `[original_id]0000000000000000`).
### Expected behavior
When reading a 64-bit Trace ID from Elasticsearch, it should be mapped to the lower 8 bytes (right-aligned) of the `pcommon.TraceID` so that the trace ID accurately reflects `0000000000000000[original_id]`.
### Relevant log output
```shell
Screenshot
No response
Additional context
I have audited the code and know how to fix the padding logic to ensure the bytes are correctly right-aligned when the decoded slice is less than 16 bytes.
I would love to contribute the fix for this issue! Could a mentor please assign this to me so I can submit a PR?
Jaeger backend version
main (v2 storage pipeline)
SDK
N/A
Pipeline
N/A
Stogage backend
v2 Elasticsearch
Operating system
All
Deployment model
N/A
Deployment configs
What happened?
There is a critical bug in the v2 Elasticsearch storage backend reader where 64-bit Trace IDs are incorrectly padded when converted to OpenTelemetry
pcommon.TraceIDtypes. This results in the complete corruption of the Trace ID.In
internal/storage/v2/elasticsearch/tracestore/ids.go, theconvertTraceIDFromDBfunction translates a DB trace ID (a hex-encoded string) into a 16-byte OpenTelemetrypcommon.TraceID.Screenshot
No response
Additional context
I have audited the code and know how to fix the padding logic to ensure the bytes are correctly right-aligned when the decoded slice is less than 16 bytes.
I would love to contribute the fix for this issue! Could a mentor please assign this to me so I can submit a PR?
Jaeger backend version
main (v2 storage pipeline)
SDK
N/A
Pipeline
N/A
Stogage backend
v2 Elasticsearch
Operating system
All
Deployment model
N/A
Deployment configs