Trace details is slow to open when the link carries a wide time window and the org has RUM data
What happens
Opening a trace from the Agent Session or LLM Insights pages, or from any shared link whose from/to spans days or weeks, can take ~30 s when the org also ingests RUM data. The same trace opens in about a second from the traces list or Session Replay, so the slowness looks intermittent.
Why
The trace-details page uses the link's whole time window, not the trace's own window, to look up the browser request that started the trace and then its page view in _rumdata. Those lookups run on unindexed columns, so each one scans every RUM row in the window (tens of millions of rows for a month) to return a handful. It does this four times per load, runs them for every trace even when it was never started from a browser, and always sends one malformed action_id IN () query whose error is silently swallowed.
Expected
Trace details should load in roughly the same time regardless of how wide the link window is. RUM lookups should be bounded by the trace's own window and skipped for traces that could not have come from a browser.
Steps to reproduce
- Org with both traces and RUM (
_rumdata) data. - Set the AI/Agent Session date picker to 30 days and open any trace from it.
- Compare with opening the same trace from the traces list with a narrow window.
Source: openobserve/openobserve