The `_trace_id_ts` table is not being used correctly in the explore view

[Defman]

The hasTraceTimestampTable is not being set correctly.

What happened:
When you click on a TraceId in explore view, it splits the view and makes searches for the trace using the query builder. However some reactivity is not being handled correctly, as the hasTraceTimestampTable is set to false. However if you make any change to force the variable to the table is detected correctly.

What you expected to happen:
The query to use the _trace_id_ts table.

How to reproduce it (as minimally and precisely as possible):
Go to explore

SELECT
  TraceId
FROM
  otel.otel_traces
WHERE
  $__timeFilter(TImestamp)

Click the TraceId and then in the new panel, click show "Show full query". Observe how the query does not contain any references to the _trace_id_ts table.

To force the update, change the table from otel_traces to otel_traces and reneable use latest otel under columns.

Observe how the query now contains references to the table _trace_id_ts.

Opening a new explore window and creating a query builder to find a single trace, do use the _trace_id_ts table.

Screenshots

Anything else we need to know?:

Environment:

• Grafana version: 13.0.0-23501141054
• Plugin version: 4.14.1
• OS Grafana is installed on: cloud
• User OS & Browser: osx firefox
• Others:

[adamyeats]

Hi @Defman — thanks for the detailed repro.

This was addressed in #1705, which moved the hasTraceTimestampTable probe out of TraceQueryBuilder and up into CHEditorByType so the _trace_id_ts optimization is applied on the first render of a trace deep-link from Explore — no longer only after a manual interaction with the query builder.

The fix is merged to main and will ship in the next plugin release. Please reopen if you still see the unoptimized query on a version that includes #1705.

Closing as resolved.