‘expand log line’ not use all filter.

[zdyj3170101136]

search with '(ServiceName:"auth-service-auth-api-service-prod" OR ServiceName:"compliance-hugebase") LogAttributes.cache:"TCP_MISS_ABORTED"'

click exact log line, it would search with:

SELECT *,Timestamp AS "__hdx_timestamp",Body AS "__hdx_body",TraceId AS "__hdx_trace_id",SpanId AS "__hdx_span_id",SeverityText AS "__hdx_severity_text",ServiceName AS "__hdx_service_name",ResourceAttributes AS "__hdx_resource_attributes",LogAttributes AS "__hdx_event_attributes" FROM default.otel_logs WHERE (Timestamp = parseDateTime64BestEffort('2025-09-11T03:35:15.038000000Z', 9) AND ServiceName = 'compliance-hugebase' AND SeverityText = '' AND Body = '' AND TimestampTime = parseDateTime64BestEffort('2025-09-11T03:35:15Z', 9)) LIMIT 1

because the search not use '(ServiceName:"auth-service-auth-api-service-prod" OR ServiceName:"compliance-hugebase") LogAttributes.cache:"TCP_MISS_ABORTED"', the log result is not correct.

field LogAttributes.cache is not TCP_MISS_ABORTED !!!

th

[MikeShi42]

This is a consequence of not being able to definitively query for a given row since there is no concept of a row ID in ClickHouse (at least not a stable row ID by default). Instead we combine the columns in the SELECT statement combined with the primary key of the table to query for the row to show when clicking in. This for the vast majority of queries will yield the correct

In this case, a short-term workaround would be to include LogAttributes.cache to the SELECT statement (or any other unique identifier)

A few long term fixes may include adding a unique log ID to each row from the ClickStack collector and using that ID if it's available to determine the specific row to query, or allowing users to customize how a unique row is determined in the table with custom additional columns.

[zdyj3170101136]

这是因为 ClickHouse 中没有行 ID 的概念（至少默认情况下没有固定的行 ID），所以无法明确查询给定的行。相反，我们会将SELECT语句中的列与表的主键组合起来，查询点击时显示的行。对于绝大多数查询来说，这都会产生正确的结果。

在这种情况下，短期解决方法是将 LogAttributes.cache 包含在SELECT语句中（或任何其他唯一标识符）

一些长期修复可能包括为 ClickStack 收集器中的每一行添加唯一的日志 ID，并在可用时使用该 ID 来确定要查询的特定行，或者允许用户使用自定义附加列自定义如何在表中确定唯一行。

i think 'include LogAttributes.cache to the SELECT statement (or any other unique identifier)' is enough.

uuid of log is difficult to handle

[MikeShi42]

The random log id can be done relatively simply and automatically inferred by HyperDX (much like how we automatically already include the primary key in the where condition on behalf of the user).

The id can be somewhat small, a UInt16 would likely do the job well enough in this case (though likely at the cost of ~2% storage increase).