feat: revamp of session view

[olzhik11]

Note

Medium Risk
Medium risk due to a substantial rewrite of the sessions UI plus new backend endpoints and LLM-assisted input extraction/caching for trace previews, which could impact performance and query correctness.

Overview
Sessions view is rebuilt from the old InfiniteDataTable/column-based UI to a custom virtualized list with expandable sessions, sticky headers, and a new SessionsStore to manage expanded state, loading, and per-session trace results (with request aborting).

Adds server-driven sorting and improved filtering for sessions via new sortColumn/sortDir URL params, updated GetSessionsSchema, and updated ClickHouse query builder ordering; advanced search now skips incomplete/empty filter tags and can omit resource to disable autocomplete.

Introduces batched trace IO previews: a new Next.js API route POST /api/projects/[projectId]/traces/io returns per-trace {input, output} previews, with client-side debounced/LRU-cached fetching for visible trace cards.

Backend support for preview grouping/caching: adds POST /api/v1/projects/{project_id}/skeleton-hashes in Rust (1–200 texts) to compute structural hashes used to group traces by system prompt, plus new frontend extraction logic that uses an LLM to generate RE2-compatible regexes and caches them (with new cache expire support) to extract the “true” user input from scaffolded messages.

^{Reviewed by Cursor Bugbot for commit 16af4cf. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR replaces the sessions table with a virtualised, expandable list (SessionsVirtualList) backed by a new Zustand store, adds server-side sorting for sessions, and introduces a batched trace I/O preview pipeline. The pipeline queries ClickHouse for the top LLM span per trace, parses multi-provider message formats, and uses LLM-generated RE2 regexes (cached in Redis/memory) to extract user inputs — all driven by a new POST /api/projects/[projectId]/traces/io route and a supporting Rust POST /skeleton-hashes endpoint.

Key changes and findings:

• N+1 ClickHouse queries: getMainAgentIOBatch fires up to 3 ClickHouse queries per trace concurrently; at the allowed 100-trace batch size this can reach 300 simultaneous queries.
• Memory cache TTL bug: CacheManager.set ignores expireAfterSeconds in non-Redis environments, so new LLM-generated regex entries never expire in memory-only deployments.
• Partial-result loss edge case: if the cached regex works for some traces but fails on one, then LLM regeneration also fails, previously refined results for the matched traces are silently overwritten with raw text.
• Sort direction SQL injection (flagged in prior review) is correctly fixed via z.enum + ternary guard.
• IO fetch error handling in useBatchedTraceIO now shows a toast as required by project conventions.

Confidence Score: 3/5

Merge-safe for UI/UX but the N+1 ClickHouse query pattern in the new batch endpoint may cause measurable latency degradation or connection-pool pressure in production under normal usage.

Two concrete, verifiable bugs remain: the N+1 ClickHouse query pattern that fires up to 300 queries per batch request (P1 performance/reliability), and the memory-cache TTL being silently ignored for non-Redis deployments (P1 correctness). The N+1 issue in particular is on the hot path for the new sessions view and will be triggered by normal user interactions, making it a production reliability concern that warrants a fix before merge.

frontend/lib/actions/sessions/trace-io.ts (N+1 queries) and frontend/lib/cache.ts (TTL ignored in memory mode) need attention before merge.

Vulnerabilities

No security concerns identified. The sortDirection SQL injection vector noted in prior review is properly remediated via z.enum([\"ASC\", \"DESC\"]) schema validation and a ternary guard before ClickHouse interpolation. The skeleton-hashes endpoint validates input size server-side. The projectId in the traces/io route is sourced from Next.js path params and overrides any attacker-supplied value in the request body.

Important Files Changed

Filename	Overview
frontend/lib/actions/sessions/trace-io.ts	New batched trace I/O fetch — fires up to 3 ClickHouse queries per trace in parallel (N+1 pattern), which at 100-trace batches can issue 300 simultaneous point-lookup queries.
frontend/lib/cache.ts	Adds expire helper (correct); however, the set method's non-Redis path ignores expireAfterSeconds, causing new regex cache entries to persist indefinitely in memory-only deployments.
frontend/lib/actions/sessions/extract-input.ts	New LLM-assisted regex extraction with caching; partial-match break discards previously resolved results when LLM regeneration subsequently fails.
frontend/lib/actions/sessions/utils.ts	Server-side sort implemented safely: sortDirection validated via z.enum and guarded with a ternary before interpolation — previously flagged SQL-injection vector is properly fixed.
frontend/components/traces/sessions-table/index.tsx	Substantial refactor replacing table with virtualized list; session expansion, sort, and pagination wiring look correct. Fetch error handling shows a toast as required by project conventions.
frontend/components/traces/sessions-table/sessions-store.tsx	New Zustand store managing expand/loading/trace state with closure-held AbortController map; JS single-threaded model makes the concurrent-access model safe for the current usage pattern.
frontend/components/traces/sessions-table/sessions-virtual-list.tsx	Virtualised list with sticky expanded session headers; range extraction and IO-loading logic look correct. Relies on useBatchedTraceIO debouncing to avoid excessive network requests.
frontend/components/traces/sessions-table/use-batched-trace-io.ts	Debounced batched fetch with LRU cache and toast on error; correctly handles abort and deduplication of in-flight/pending IDs.
frontend/lib/actions/sessions/parse-input.ts	Multi-provider message parsing (OpenAI/Anthropic/Gemini); Gemini extraction guard on line 128 has ambiguous logic for role-less content (pre-existing, flagged in prior thread).
app-server/src/routes/spans.rs	New POST /skeleton-hashes endpoint validates input size (1–200) and returns structural hashes; clean error handling with no panics.

Comments Outside Diff (1)

1. frontend/lib/cache.ts, line 94-96 (link)

   expireAfterSeconds silently ignored in non-Redis environments

   When REDIS_URL is not set, the else branch stores every entry with expiresAt: null, completely ignoring the expireAfterSeconds option. The new LLM-generated regex cache in extract-input.ts calls:

   await cache.set(cacheKey, regex, { expireAfterSeconds: SEVEN_DAYS_SECONDS })

   In a non-Redis deployment, this regex is cached forever — the intent of a 7-day rolling TTL is silently lost, and the in-memory Map grows without bound as more unique systemHash values are seen.

   Apply the TTL in the memory path too:

   } else {
     const expiresAt = options.expireAfterSeconds
       ? Date.now() + options.expireAfterSeconds * 1000
       : options.expireAt
         ? options.expireAt.getTime()
         : null;
     this.memoryCache.set(key, { value, expiresAt });
   }

_{Reviews (6): Last reviewed commit: "feat: fix comment" | Re-trigger Greptile}

[greptile-apps]

Concurrent requests with the same systemHash will both call the LLM

When a cached regex exists but partially fails (allMatched = false), cache.remove is called and the function falls through to regenerate. Between cache.remove and the new cache.set, any concurrent request that shares the same systemHash will also find a cache miss and independently invoke generateExtractionRegex. Since generateExtractionRegex is non-deterministic (LLM), the two concurrent calls could produce slightly different regexes, and the last write wins.

Per the project's rule on global mutable state and race conditions, this should at least be documented. If different regex results are a real concern, a distributed lock or a "write-once" check on the cached value would be safer:

// Only cache if the key is still absent (write-once semantics)
const stillMissing = !(await cache.exists(cacheKey));
if (anyMatch && stillMissing) {
  await cache.set(cacheKey, regex, { expireAfterSeconds: SEVEN_DAYS_SECONDS }).catch(() => {});
}

Rule Used: Document any potential race conditions with global... (source)

Learnt From
lmnr-ai/lmnr-ts#72

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for all 3 issues found in the latest run.

• ✅ Fixed: Exported TraceTimelineItem type is unused dead code
  • Removed the unused exported TraceTimelineItem type from the traces types module.
• ✅ Fixed: Stale closure causes session toggle to malfunction
  • Added a store-level isSessionExpanded getter and used it in the toggle handler so expansion state is read from current store state instead of a stale closure.
• ✅ Fixed: Missing shallow equality causes excessive re-renders
  • Updated the actions selector useSessionsStoreContext call to use shallow, preventing unnecessary re-renders from new object literals.

Or push these changes by commenting:

@cursor push 30ffabbb6e

Preview (30ffabbb6e)

diff --git a/frontend/components/traces/sessions-table/index.tsx b/frontend/components/traces/sessions-table/index.tsx
--- a/frontend/components/traces/sessions-table/index.tsx
+++ b/frontend/components/traces/sessions-table/index.tsx
@@ -63,6 +63,7 @@
 
   const {
     expandSession,
+    isSessionExpanded,
     collapseSession,
     setLoadingSession,
     setSessionTraces,
@@ -70,16 +71,20 @@
     setLoadingSessionIO,
     resetExpandState,
     getController,
-  } = useSessionsStoreContext((state) => ({
-    expandSession: state.expandSession,
-    collapseSession: state.collapseSession,
-    setLoadingSession: state.setLoadingSession,
-    setSessionTraces: state.setSessionTraces,
-    mergeTraceIO: state.mergeTraceIO,
-    setLoadingSessionIO: state.setLoadingSessionIO,
-    resetExpandState: state.resetExpandState,
-    getController: state.getController,
-  }));
+  } = useSessionsStoreContext(
+    (state) => ({
+      expandSession: state.expandSession,
+      isSessionExpanded: state.isSessionExpanded,
+      collapseSession: state.collapseSession,
+      setLoadingSession: state.setLoadingSession,
+      setSessionTraces: state.setSessionTraces,
+      mergeTraceIO: state.mergeTraceIO,
+      setLoadingSessionIO: state.setLoadingSessionIO,
+      resetExpandState: state.resetExpandState,
+      getController: state.getController,
+    }),
+    shallow
+  );
 
   // Serialize filter array for stable dependency comparison
   const filterKey = JSON.stringify(filter);
@@ -157,7 +162,7 @@
 
   const handleToggleSession = useCallback(
     async (sessionId: string) => {
-      const isExpanded = expandedSessions.has(sessionId);
+      const isExpanded = isSessionExpanded(sessionId);
 
       if (isExpanded) {
         collapseSession(sessionId);
@@ -226,13 +231,13 @@
       }
     },
     [
-      expandedSessions,
       pastHours,
       startDate,
       endDate,
       projectId,
       toast,
       expandSession,
+      isSessionExpanded,
       setLoadingSession,
       setSessionTraces,
       mergeTraceIO,

diff --git a/frontend/components/traces/sessions-table/sessions-store.tsx b/frontend/components/traces/sessions-table/sessions-store.tsx
--- a/frontend/components/traces/sessions-table/sessions-store.tsx
+++ b/frontend/components/traces/sessions-table/sessions-store.tsx
@@ -15,6 +15,7 @@
 };
 
 export type SessionsActions = {
+  isSessionExpanded: (sessionId: string) => boolean;
   expandSession: (sessionId: string) => void;
   collapseSession: (sessionId: string) => void;
   setLoadingSession: (sessionId: string, loading: boolean) => void;
@@ -40,9 +41,11 @@
 export const createSessionsStore = () => {
   const sessionControllers = new Map<string, AbortController>();
 
-  return createStore<SessionsStore>()((set) => ({
+  return createStore<SessionsStore>()((set, get) => ({
     ...DEFAULT_STATE,
 
+    isSessionExpanded: (sessionId) => get().expandedSessions.has(sessionId),
+
     expandSession: (sessionId) =>
       set((state) => {
         const next = new Set(state.expandedSessions);

diff --git a/frontend/lib/traces/types.ts b/frontend/lib/traces/types.ts
--- a/frontend/lib/traces/types.ts
+++ b/frontend/lib/traces/types.ts
@@ -191,14 +191,6 @@
   outputMessageIds: string[];
 };
 
-export type TraceTimelineItem = {
-  id: string;
-  name?: string;
-  startTime: string;
-  endTime: string;
-  status: string;
-};
-
 // We have id and sessionId here because
 // its not possible to make good type intersection,
 // and use it in tanstack table wrappers.

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

[greptile-apps]

Tip:

Greploop — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.

Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.

[greptile-apps]

Ambiguous continue condition may process wrong message

The compound guard on the skip condition is confusing and can produce incorrect results:

if (content.role !== "user" && (content.role || i === 0)) continue;

When iterating backwards, for any message at index i > 0 that has no role set (null / undefined), the expression evaluates:

• content.role !== "user" → true
• (content.role || i === 0) → (falsy || false) → false

So the guard does not skip it — the function returns that roleless message as if it were the last user turn. A Gemini streaming response whose final content object lacks a role field would be incorrectly treated as user input.

If the intent is to fall back to the last rolelessly-typed message, this should be documented explicitly. Otherwise, simplify to:

Suggested change

	const content = contents[i];
	if (content.role !== "user" && (content.role || i === 0)) continue;
	if (content.role !== "user") continue;

[greptile-apps]

Partial cached-regex results are silently discarded when LLM regeneration fails

When the cached regex matches some traces but fails on one (causing allMatched = false + break), the results for the already-matched traces are written into results. The function then falls through to the LLM path.

If generateExtractionRegex returns null (LLM timeout, API unavailable), the code does:

if (!regex) {
  for (const trace of traces) {
    results[trace.traceId] = { input: joinUserParts(...), output: trace.output };
  }
  return;
}

This overwrites the previously-extracted (and more refined) values for the traces that did match the cached regex with raw unfiltered text. The user experiences degraded output quality for no reason.

One simple fix: preserve the results that were successfully extracted before the fallback overwrites them:

if (!regex) {
  for (const trace of traces) {
    if (!(trace.traceId in results)) {
      results[trace.traceId] = { input: joinUserParts(trace.parsed?.userParts ?? []), output: trace.output };
    }
  }
  return;
}

[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.}

^{Reviewed by Cursor Bugbot for commit 16af4cf. Configure here.}