feat: signals UI enhancement

[kolbeyang]

Note

Medium Risk
Touches core Signals events browsing by adding cluster-based filtering, new stats queries, and a redesigned events table; errors here could change query results or UI navigation. Changes span both frontend state management and ClickHouse query construction.

Overview
Signals Events UI is reworked around event clusters. The old clusters table + single-series events chart are removed and replaced with a new resizable ClustersSection (drill-down list, breadcrumb navigation, and stacked time-series chart) driven by new Zustand cluster state/selectors and URL clusterId query state (via nuqs).

Events table becomes schema-driven and supports cluster filtering. Columns/filters are now generated from the signal output schema (payload fields become typed columns with tooltips and boolean/enum rendering), row selection opens a new event detail side panel, and trace navigation is improved with copy/open-trace controls.

Backend/query changes to support the UI. Cluster APIs now return total vs clustered counts and add a new /events/clusters/stats endpoint for per-cluster time-series; events pagination adds clusterId[] and unclustered filters (ClickHouse hasAny(clusters, …) / empty(clusters)), payload filtering is updated to understand payload.<field> with typed comparisons, and the query engine validator allows the signal_events.clusters column.

^{Written by Cursor Bugbot for commit 3dfe965. This will update automatically on new commits. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[kolbeyang]

bugbot run

[kolbeyang]

bugbot run

[kolbeyang]

bugbot run

[kolbeyang]

@olzhik11 is there a better way to handle UNCLESTERED_ID thing here?

[kolbeyang]

bugbot run

[kolbeyang]

Hmm generateSql actually isn't exported from @/lib/actions/sql so this seems correct

[kolbeyang]

Same here, this is the correct import because it's not exported from actions/sql/index.ts

[olzhik11]

@kolbeyang i think here we don't need to loop again, it should return as number already if not mistaken, and we can return unclustered id right away in query,

SELECT
  '00000000-0000-0000-0000-000000000000' as cluster_id,
  toStartOfInterval(timestamp, toInterval({intervalValue: UInt32}, {intervalUnit: String})) as ts,
  count() as count

or modify type to make it optional, this would ease logic

[kolbeyang]

@olzhik11 For this one do you think unclustered should be unified with the other clusters using UNCLUSTERED_ID?

Currently I treat it as kind of its own thing in the store

        set({
          rawClusters: data.items,
          clusterTree: buildTree(data.items),
          totalEventCount: data.totalEventCount,
          clusteredEventCount: data.clusteredEventCount,
        });

[olzhik11]

separately is fine i think

[olzhik11]

I like the selectors approach, very clean, just for reference we can do it this way:

export const getBreadcrumb = (state: Store, clusterId: string | null): ClusterNode[] => { ... };

const breadcrumb = useSignalStoreContext((state) => getBreadcrumb(state, clusterId));

here we would not need to use useMemo

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Missing shallow equality causes unnecessary event refetches
  • Added Zustand shallow equality to the selectedClusterIds selector so unchanged cluster ID arrays no longer trigger infinite-scroll dependency resets and redundant event refetches.

Or push these changes by commenting:

@cursor push 4451e1e41b

Preview (4451e1e41b)

diff --git a/frontend/components/signal/events-table/index.tsx b/frontend/components/signal/events-table/index.tsx
--- a/frontend/components/signal/events-table/index.tsx
+++ b/frontend/components/signal/events-table/index.tsx
@@ -3,6 +3,7 @@
 import { type Row } from "@tanstack/react-table";
 import { useParams, usePathname, useRouter, useSearchParams } from "next/navigation";
 import { useCallback, useEffect, useMemo } from "react";
+import { shallow } from "zustand/shallow";
 
 import ClustersSection from "@/components/signal/clusters-section";
 import ClusterBreadcrumbs from "@/components/signal/clusters-section/cluster-breadcrumbs";
@@ -59,7 +60,7 @@
   const [clusterId] = useClusterId();
   const signal = useSignalStoreContext((state) => state.signal);
   const selectedEvent = useSignalStoreContext((state) => state.selectedEvent);
-  const selectedClusterIds = useSignalStoreContext((state) => getFilterClusterIds(state, clusterId));
+  const selectedClusterIds = useSignalStoreContext((state) => getFilterClusterIds(state, clusterId), shallow);
   const isUnclusteredFilter = clusterId === UNCLUSTERED_ID;
   const searchParams = useSearchParams();
   const pathName = usePathname();

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

ClickHouse WITH FILL creates incorrect cross-cluster rows

Medium Severity

The cluster time-series query orders by cluster_id, timestamp and appends a WITH FILL clause. In ClickHouse, WITH FILL fills gaps between consecutive rows in the result. Because ordering is by cluster_id first, the fill will generate spurious rows between the last timestamp of one cluster and the first timestamp of the next, assigning incorrect cluster_id values to the filled rows. The unclustered query doesn't have this issue since it has no grouping column.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Stacked chart data points missing required count field

Low Severity

Data points created for the stacked chart are cast as TimeSeriesDataPoint but never set the required count property — only dynamic cluster-ID keys are populated. This works now because showTotal={false} is passed, but if showTotal were ever omitted or set to true, accessing d.count would yield undefined, producing NaN in totals. The as cast silently masks this type violation.

 

[kolbeyang]

Not a real issue. TimeSeriesDataPoint is typed as { timestamp: string } & Record<string, number> — there is no required count field. The dynamic cluster-ID keys satisfy the type correctly.

Additionally, totalCount (used when showTotal is true) iterates Object.entries(dataPoint) and sums all numeric values, skipping "timestamp" — it never accesses a .count property. So even with showTotal={true}, this would work fine.

[olzhik11]

lgtm @kolbeyang, lets check last comment