Possible Task “This Trace” logs correlation bug: Task ID may be used as OTEL `traceId`

[andersou]

Summary

The non-root Task’s This Trace tab may be querying logs with a Task/span-related identifier rather than the actual OpenTelemetry trace ID.

The Task page passes the following value to TraceLogsPanel:

<TraceLogsPanel
    projectId={projectsState.currentProjectId ?? ''}
    traceId={traceIdUuidToHex(response.task.id)}
    distributedTraceId={response.task.distributedTraceId ?? null}
    spans={response.spans ?? []}
/>

TraceLogsPanel then uses traceId to query logs.

Is response.task.id intentionally meant to represent the OTEL trace ID for non-root Tasks? If not, this may be a mapping/correlation issue. The actual OTEL trace ID should likely be used for traceId, with the span ID passed separately when span-level filtering is required.

Observed behavior

Observed with the v1.19.23-sqlite image, before applying any Collector ID rewriting.

OpenTelemetry identifiers have different semantics:

• trace_id: 128-bit / 32 hexadecimal characters.
• span_id: 64-bit / 16 hexadecimal characters.

In a captured request, the consumer span ID was 1985a7abed0024db, and the logs request used its zero-padded 32-character form:

traceId = 00000000000000001985a7abed0024db

The stored log contained:

traceId     = 8462dd06157032df3c6c90ac5ff74ed7
spanId      = 1985a7abed0024db
serviceName = example-worker

Query results:

Filter	Matching logs
Original OTEL traceId	4
Consumer spanId	4
Zero-padded occurrence ID as traceId	0

This suggests the potential issue is semantic identifier mapping, even when the request value contains 32 characters.

This report concerns the non-root Task’s This Trace tab. All Distributed Traces may work when an upstream root is stored in the project.

Expected behavior

• Opening a Task queries logs using the actual OTEL trace_id.
• Opening a specific span either queries all logs sharing that trace_id, or filters using both trace_id and span_id.
• A span-derived Task occurrence ID should not be used as the traceId filter unless it represents the stored OTEL trace ID.

Steps to reproduce

1. Send OTEL traces and correlated logs with known trace_id and span_id values.
2. Open a non-root Task or child span in Traceway.
3. Open the This Trace tab.
4. Inspect the logs request in browser DevTools.
5. Compare its traceId filter with the original OTEL trace and span IDs.
6. Check whether the value corresponds to the span ID—including a zero-padded 32-character variant—instead of the actual trace ID.

Possible source

The likely mapping point is the Task page passing:

traceId={traceIdUuidToHex(response.task.id)}

to TraceLogsPanel, rather than an explicit OTEL trace identifier.

Relevant source revision.

PR #182, feat: added logs on tasks and ai traces (June 5, 2026), is historical context only; this report does not assert that it caused the behavior.

[dusanstanojeviccs]

This should now be fully resolved in V2 of traceway @andersou please confirm it works as expected and close the issue