What happened?
Elasticsearch service-operation document IDs can collide for different service/operation pairs.
The current hashCode function writes ServiceName and OperationName directly into the same FNV hash without encoding a boundary between them.
For example, these two distinct pairs produce the same input bytes (abc):
- Service name:
ab, operation name: c
- Service name:
a, operation name: bc
Steps to reproduce
-
Create two service-operation pairs:
ServiceName: "ab", OperationName: "c"ServiceName: "a", OperationName: "bc"
-
Pass both pairs through the current service-operation hashCode implementation.
-
Observe that both pairs write the same byte sequence (abc) to the FNV hash.
-
As a result, both pairs produce the same ID even though the (ServiceName, OperationName) tuples are different.
The same collision can affect batch deduplication when both pairs are submitted together.
Expected behavior
Different (ServiceName, OperationName) pairs should produce unambiguous hash inputs and therefore distinct service-operation IDs.
For example, ("ab", "c") and ("a", "bc") should not produce the same ID.
Relevant log output
Screenshot
No response
Additional context
Verified on main at commit 70b78d8c.
A possible fix would be to encode field boundaries unambiguously before hashing, for example by prefixing each value with its length.
Regression tests could verify that:
("ab", "c") and ("a", "bc") produce different IDs- both pairs are included when submitted in one batch
- submitting the same pair repeatedly still deduplicates correctly
Since changing the hash input would change document IDs, existing service-operation documents may retain their old IDs until they are replaced. Elasticsearch term aggregations should still deduplicate identical service/operation values, but maintainer guidance on the expected backward-compatibility behavior would be appreciated.main (70b78d8c)
Jaeger backend version
main (70b78d8c)
SDK
No response
Pipeline
No response
Stogage backend
Elasticsearch
Operating system
No response
Deployment model
No response
Deployment configs
What happened?
Elasticsearch service-operation document IDs can collide for different service/operation pairs.
The current
hashCodefunction writesServiceNameandOperationNamedirectly into the same FNV hash without encoding a boundary between them.For example, these two distinct pairs produce the same input bytes (
abc):ab, operation name:ca, operation name:bcSteps to reproduce
Create two service-operation pairs:
ServiceName: "ab",OperationName: "c"ServiceName: "a",OperationName: "bc"Pass both pairs through the current service-operation
hashCodeimplementation.Observe that both pairs write the same byte sequence (
abc) to the FNV hash.As a result, both pairs produce the same ID even though the
(ServiceName, OperationName)tuples are different.The same collision can affect batch deduplication when both pairs are submitted together.
Expected behavior
Different
(ServiceName, OperationName)pairs should produce unambiguous hash inputs and therefore distinct service-operation IDs.For example,
("ab", "c")and("a", "bc")should not produce the same ID.Relevant log output
Screenshot
No response
Additional context
Verified on
mainat commit70b78d8c.A possible fix would be to encode field boundaries unambiguously before hashing, for example by prefixing each value with its length.
Regression tests could verify that:
("ab", "c")and("a", "bc")produce different IDsSince changing the hash input would change document IDs, existing service-operation documents may retain their old IDs until they are replaced. Elasticsearch term aggregations should still deduplicate identical service/operation values, but maintainer guidance on the expected backward-compatibility behavior would be appreciated.main (
70b78d8c)Jaeger backend version
main (
70b78d8c)SDK
No response
Pipeline
No response
Stogage backend
Elasticsearch
Operating system
No response
Deployment model
No response
Deployment configs