dotnet-trace Chromium conversion silently drops ActivitySource events

[agocke]

Description

dotnet-trace convert --format Chromium silently produces an empty Chromium trace for a valid EventPipe trace containing ActivitySource spans bridged through Microsoft-Diagnostics-DiagnosticSource.

I first encountered this on a trace containing 1,432 Activity/Start events and 1,432 corresponding Activity/Stop events. A TraceEvent-based reader can enumerate those events and their payloads, but the converted file contains:

{
  "traceEvents": [],
  "stackFrames": {}
}

The converter exits successfully and does not indicate that the activity events were omitted.

Reproduction

Create activity-repro.cs:

#:property PublishAot=false

using System.Diagnostics;

Activity.DefaultIdFormat = ActivityIdFormat.W3C;
Activity.ForceDefaultIdFormat = true;

using var source = new ActivitySource("ActivitySource.EventPipe.Repro");
using (source.StartActivity("Parent"))
{
    using (source.StartActivity("Child"))
    {
        Thread.Sleep(100);
    }
}

Collect and convert the trace:

dotnet-trace collect \
  --providers 'Microsoft-Diagnostics-DiagnosticSource:0x3:5:FilterAndPayloadSpecs=[AS]ActivitySource.EventPipe.Repro' \
  --format NetTrace \
  --output activity-repro.nettrace \
  -- dotnet activity-repro.cs

dotnet-trace convert --format Chromium activity-repro.nettrace

The .nettrace contains Microsoft-Diagnostics-DiagnosticSource/ActivityStart and ActivityStop events. The resulting activity-repro.chromium.json contains no trace events.

Expected behavior

Ideally the converter would emit Chromium complete events or begin/end events for the activities, including their parent-child relationship.

If DiagnosticSource activities are intentionally unsupported by the Chromium converter, conversion should report that those events were omitted instead of silently producing a successful empty trace.

Configuration

• dotnet-trace: 9.0.661903+d7b455b46332b31fd9ba3a3f3e020387984c511a
• Runtime: Microsoft.NETCore.App 11.0.0-preview.7.26360.111
• OS: Ubuntu 24.04 under WSL2
• Architecture: x64

Regression?

Unknown.

Other information

The events can be recovered using a custom TraceEvent reader, so the EventPipe collection itself is successful. The current workaround is to parse ActivityStart/ActivityStop and their Arguments payload directly.

Related runtime behavior is being reported separately: the bridged events expose empty TraceEvent.ActivityID and RelatedActivityID, while their W3C identifiers are only present in the generic payload.