Node spans now emitted in workflow traces

Before this change, n8n only traced workflows as a single unit. When something went wrong, developers had to piece together what happened by parsing logs or manually instrumenting their nodes.

Workflows can now be traced at the individual node level. Each node that executes generates its own span nested within the workflow span, capturing the node ID, name, type, version, input item count, and output item count. If a node throws an error, the span is marked with error status and includes exception details. Nodes can also write arbitrary key-value pairs to a new tracing bag, which gets attached to the span as custom attributes for deeper introspection.

When a workflow is cancelled, any nodes still running get their spans closed with a termination reason of "workflow_cancelled" so traces remain consistent. Node span tracing is enabled by default but can be disabled via the N8N_OTEL_TRACES_INCLUDE_NODE_SPANS environment variable.

The tracing bag lets node developers add custom telemetry without touching the core instrumentation layer—write to taskData.metadata.tracing, and it appears in OTEL with a n8n.node.custom. prefix. This makes it straightforward to trace business logic events, record processing milestones, or surface debug information that would otherwise require digging through logs.

This lives in the @n8n/otel module within the CLI package and builds on the existing workflow-level tracing infrastructure that was already in place.