You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Guillaume Nodet (Jira)" <ji...@apache.org> on 2026/07/10 14:45:00 UTC
[jira] [Created] (CAMEL-23993) Flaky SpanPropagationUpstreamTest - SpanComparator missing tie-breaking on equal timestamps
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)