Flaky OTel conformance runs: Dash0 trace lookup timeout, Datadog span timestamp precision

[yaythomas]

Two OTel conformance jobs on aws-durable-execution-sdk-js main failed this week for backend-side reasons. Both passed on re-run with no code change.

1. Dash0: trace not found within 60s

• Run: https://github.com/aws/aws-durable-execution-sdk-js/actions/runs/34656879075/attempts/1 (job "Invocation view / Invocation - Community/Dash0")
• Passing re-run: https://github.com/aws/aws-durable-execution-sdk-js/actions/runs/34656879075/job/103457254699
• Cases otel-invocation-1 through otel-invocation-4 failed. The other 16 passed.

OpenTelemetry backend validation failed: No correlated trace was found in backend 'dash0' after 27 attempt(s) within 60s

2. Datadog: child span starts "before" parent by sub-second skew

• Run: https://github.com/aws/aws-durable-execution-sdk-js/actions/runs/34285306622/job/102661500049 (job "Invocation view / Invocation - Community/Datadog")
• Case otel-invocation-3 (Otel3Retry) failed. The other 19 passed.

span_assertions[4].expect.parent: child span 'otel-retry attempt 1' starts at 2026-09-09T22:14:46+00:00, before parent span 'otel-retry' starts at 2026-09-09T22:14:46.697000+00:00

The child timestamp has whole-second precision. The parent has millisecond precision. So the backend appears to truncate one of them on ingest.

Possible fixes

• Raise the Dash0 trace-lookup timeout above 60s, or make it backend-configurable.
• Make the parent/child start-time assertion tolerate sub-second skew when a backend reports whole-second timestamps.

[zhongkechen]

Datadog and dash0 Tests have been removed

[yaythomas]

consuming repos are still pinned to the old broken version

moving the pin forward:

aws/aws-durable-execution-sdk-js#919

aws/aws-durable-execution-sdk-python#724

Java still pending, still needs Dependabot to create PR.