You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(core): give each run its own external fallback trace id
Runs that carry no external trace context (schedules, task-to-task
triggers) fall back to a trace id generated once in the TracingSDK
constructor. With `experimental_processKeepAlive` the TracingSDK outlives
the run, so every run on a warm process was exported to the external OTLP
endpoint under that one id, merging unrelated runs into a single trace.
Across our production traces, 80.3% contained spans from more than one
run, worst case 25.
This is the same warm-start hazard c043c4a fixed for the external
context path, which read the context live but deliberately left the
fallback captured at construction.
Key the fallback off the internal trace id that every span and log record
of a run already carries, rather than off ambient state. Batch processors
drain asynchronously, so a run's records are routinely exported after the
next run has started; deciding the id at export time from whatever run is
current would stamp the earlier run's records with the later run's id.
Letting the record decide sidesteps the timing entirely, and makes a run's
spans and logs agree without coordinating.
The map is bounded, since a warm process serves unboundedly many runs and
only the in-flight ones can still have records to export. An empty
configured id still means external export is off.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Runs that don't continue an incoming trace are no longer merged into one trace when they execute on the same warm worker process. Each run now appears as its own trace in your external observability tool, so per-run cost and latency attribution works again.
0 commit comments