## Problem/Motivation Sites that run the [OpenTelemetry](https://www.drupal.org/project/opentelemetry) module trace every request: its database queries, its exceptions, and the calls it makes elsewhere. Each request gets a W3C Trace Context trace ID. That ID can travel to other systems through `traceparent` (queues, webhooks, MCP tool calls). Nothing links an audit row to that trace. An operator reading "this entity was deleted" cannot open what else happened in the same request, or why it failed or was slow. #3620443 added a `trace_id` column to every chained row, and a trace ID provider service in base that returns NULL. Something has to tell it the current trace. ## Proposed resolution Add an `audit_trail_opentelemetry` submodule that decorates the trace ID provider from #3620443. It returns the current span's trace ID, read with `Span::getCurrent()`. When no valid span is current, it asks the provider it decorates: NULL from the base module, or another module's trace ID if one also decorates the service. - **It depends on the `open-telemetry/api` library, not on the OpenTelemetry module.** The OpenTelemetry module makes its root span current through that same library, and so does the PHP extension, so the decorator works with either. The OpenTelemetry module also does not declare Drupal 12 support yet. `open-telemetry/api` goes to `suggest` and `require-dev`, and an install-time requirement refuses to install the submodule without it. - **A submodule, not base code**, because it is what carries that library dependency, and enabling it is the operator's decision. - **Every chained row gets the trace ID**, because the writer asks the provider, whatever path the entry came through. An earlier version of this issue, and of !179, used a context contributor writing `opentelemetry.trace_id` and `opentelemetry.span_id` to `context_permanent`. That is replaced: the contributor only reached entries recorded through `AuditTrail::record()`, had no index, and kept the IDs signed for good, while a trace ID is transient data (see #3620443). The span ID is dropped: the trace ID is what links a row to its trace. ## Limits to document - **An incoming trace ID is chosen by the client.** When a trace continues from an incoming `traceparent` header, the sender picks the trace ID. The ID links a row to a trace. It proves nothing about who sent the request. Sites that clients outside their control can reach should turn on *Ignore parent for root span* in the OpenTelemetry module's settings, so every request starts a trace of its own. - **A recorded trace ID does not mean the backend kept the trace.** A span the sampler dropped still has a valid ID. - **One trace is one execution, not one business operation.** A process that resumes in a later request starts a new trace unless the caller links it. `correlation_id` is for the business operation. - **The trace ID is cleared with the transient context.** Grouping rows by trace works within the transient retention window, which is when an investigation needs it. That purge is off until `transient_purge_after` is set; until then, the trace ID is kept as long as the row, and archives carry it. - **Outside any span, rows get no trace ID.** That is the case in cron and drush unless something traces them. ## Remaining tasks - Review !179. It is rebased on 1.x now that #3620443 has landed, and replaces the contributor with the decorator. ## User interface changes None of its own. The trace ID filter comes from #3620443. ## API changes None. ## Data model changes None. The `trace_id` column comes from #3620443. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the first version of the submodule and its test. I reviewed them.)