Active record async queries are considered separate traces #3465
Comments
agrobbin
added a commit
to agrobbin/dd-trace-rb
that referenced
this issue
Mar 28, 2025
When leveraging Active Record's async query functionality (`load_async`, `async_count`, etc.), the queries are executed in a different thread, via concurrent-ruby's `ThreadPoolExecutor`. This causes the span for that query to not show up in the parent trace (often a `rack.request`). Now, the Active Record integration (for anything greater than v7.0.0) will wrap `ConnectionPool#build_async_executor` with the already-existing `ContextCompositeExecutorService` from the concurrent-ruby tracer integration, ensuring that the current trace is continued within the thread. Closes DataDog#3465.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behaviour
When leveraging Active Record's async queries functionality (
load_async,async_count, etc.), the queries that are executed, while noticed by ddtrace and wrapped in spans, are considered separate traces, and are therefore not easily discoverable / correlated to the overall trace (whether it be a web request, background job, or something else).After looking briefly at the ddtrace source, my hunch is that the reason these are not all part of the same trace is that the query is executed in a different thread from the main trace, and ddtrace is not referencing the parent trace correctly.
Expected behaviour
Active Record async queries should be part of the overall trace.
Steps to reproduce
With diagnostics turned on locally, you can clearly see the trace ID attached to the async query spans is different for each query, and not the same as the overall request trace ID.
Environment
Datadog.configure ...):The text was updated successfully, but these errors were encountered: