Guillaume Nodet created CAMEL-23993:
---------------------------------------
Summary: Flaky SpanPropagationUpstreamTest - SpanComparator
missing tie-breaking on equal timestamps
Key: CAMEL-23993
URL: https://issues.apache.org/jira/browse/CAMEL-23993
Project: Camel
Issue Type: Bug
Components: camel-telemetry
Reporter: Guillaume Nodet
SpanPropagationUpstreamTest is flaky across all telemetry modules
(camel-telemetry, camel-telemetry-dev, camel-micrometer-observability,
camel-opentelemetry2).
Develocity shows a ~20% failure rate (35/175 runs).
*Root cause:* SpanComparator sorts spans by start timestamp only. When spans
have identical start timestamps (common on fast systems where execution happens
within the same nanosecond), the sort is non-deterministic. Java's TimSort
preserves insertion order for equal elements, and InMemorySpanExporter adds
spans in end-order (innermost/leaf spans end first). This reverses the expected
creation-order, causing positional assertions like {{spans.get(0)}} to retrieve
the wrong span.
*Fix:* Add {{endEpochNanos}} (descending) as a secondary sort key in
SpanComparator. Parent spans always end after their children, so when start
times tie, sorting by end time descending puts parent spans first — matching
the hierarchy order the tests expect.
The fix applies to all 4 SpanComparator implementations:
-
{{components/camel-micrometer-observability/.../CamelOpenTelemetryExtension.java}}
- {{components/camel-opentelemetry2/.../CamelOpenTelemetryExtension.java}}
- {{components/camel-telemetry/.../mock/MockTrace.java}}
- {{components/camel-telemetry-dev/.../DevTrace.java}}
Additionally, the mock-based comparators (camel-telemetry, camel-telemetry-dev)
used {{(int)(longA - longB)}} which has an integer overflow bug. The fix uses
{{Long.compare()}} instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
