Fix slow traceId lookup

[stackempty]

Type of Change

Please check the relevant option.

• 🚀 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧹 Refactor / Chore

---

Bug Fix

What is the bug?

When navigating to a trace via "View trace" from a log line (or any trace deep-link), the first SQL query generated is unoptimized — it uses a simple WHERE traceID = '' filter instead of the optimized query that leverages the _trace_id_ts materialized view to narrow the time range. The optimized query only appeared after manual UI interaction (expanding the query builder, clicking in/out of the trace ID input, etc.).

The unoptimized query either takes very long or would timeout on very large tables ... causing the traceview not to load on first try without clicking in and out of the traceId box.

The root cause is that the _trace_id_ts optimization in generateTraceIdQuery required a hasTraceTimestampTable flag in the query metadata. This flag was populated by TraceQueryBuilder after an async useTables() fetch completed, and was only written into the builder options on user interaction via onOptionChange. The first SQL generation always ran before either of those could happen, so the optimization was never applied on the initial query.

How to reproduce

Provide step-by-step instructions to reproduce the bug.

1. Configure a ClickHouse datasource with OTel tracing enabled. - I have used the public clickhouse database with otel tables in the demo below.
2. Run a logs query that returns rows with trace IDs.
3. Click "View trace" on a log line.
4. Observe the generated SQL — it will be WHERE traceID = '' without the WITH ... trace_start / trace_end optimization.
5. Expand the query builder or interact with the trace ID input.
6. Observe the SQL regenerates with the optimization.

Environment (if no related issue)

If there is no open issue, please specify the versions where the bug occurs.

• ClickHouse version: 25.12
• Grafana version: 12.4.0
• Plugin version: 4.14.0

---

Screenshots / Videos

Please provide screenshots or videos demonstrating the bug or the feature working. This helps reviewers understand the change visually and speeds up the review process.

Before	After

---

Please check that:

• Tests for this change have been added/updated.
• Documentation has been added/updated (where applicable).

Special notes for your reviewer

Fix (3 files):

src/data/utils.ts — Pre-generate rawSql via generateSql() when building the trace ID data link. For logs→trace links with OTel enabled, set hasTraceTimestampTable: true so the optimization is included. Trace ID queries don't contain $__fromTime/$__toTime, so the original empty-rawSql workaround doesn't apply to them.

src/views/CHQueryEditor.tsx — Moved the useTables / hasTraceTimestampTable resolution from TraceQueryBuilder up to CHEditorByType, so it runs even when the builder is minimized via deep-links. If the actual table check disagrees with the link's optimistic value, SQL is regenerated.

src/components/queryBuilder/views/TraceQueryBuilder.tsx — Removed the useTables hook, hasTraceTimestampTable computation, and its sync useEffect, since this logic now lives in CHEditorByType.

Relationship to #1663: The hasTraceTimestampTable guard in sqlGenerator.ts is fully preserved. If the _trace_id_ts table doesn't actually exist, the async table check in CHEditorByType will correct the optimistic value and regenerate unoptimized SQL.

Given that _trace_id_ts is a standard OTel table, the optimistic approach and preferring to use that table is correct for most use cases and existing systems, without this clicking for log -> trace forces everyone into an unoptimized path causing a bad experience.