[
https://issues.apache.org/jira/browse/CAMEL-23993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-23993 started by Guillaume Nodet.
-----------------------------------------------
> 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
> Assignee: Guillaume Nodet
> Priority: Major
>
> 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)
