packages/console-frontend/src/components/ui/card.tsx (1)

27-37: Good fix: CardTitle now correctly renders children.

The change from a self-closing <h3 {...props} /> to explicit <h3>{children}</h3> is correct—spreading props on a self-closing tag doesn't render children in JSX.

Pre-existing type mismatch: The ref type is HTMLParagraphElement but the element is <h3> (HTMLHeadingElement). Consider aligning the types:

🔧 Suggested fix for type consistency

 export const CardTitle = React.forwardRef<
-  HTMLParagraphElement,
+  HTMLHeadingElement,
   React.HTMLAttributes<HTMLHeadingElement>
 >(({ className, children, ...props }, ref) => (

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/ui/card.tsx` around lines 27 - 37,
The CardTitle forwardRef has a type mismatch: the ref is declared as
HTMLParagraphElement while the component renders an <h3> (a heading). Update the
generics and ref type on CardTitle to use HTMLHeadingElement and
React.HTMLAttributes<HTMLHeadingElement> so the ref and props match the rendered
<h3> element (update the forwardRef signature and ref generic accordingly).

packages/console-frontend/src/components/traces/TraceMap.tsx (1)

100-117: Defensive null check is good, but angle calculation has a subtle issue if filtering ever occurs.

The refactor to .map().filter() with type narrowing is idiomatic. However, since serviceNames comes from serviceMap.keys() (line 94), serviceMap.get(name) will always return a defined value—the null check is purely defensive.

The subtle issue: angles are computed using index i and nodeCount from the pre-filter array. If a node were ever filtered out, the circular layout would have gaps instead of redistributing evenly. This is currently unreachable but would become a bug if the logic ever changes.

♻️ Option: recalculate angles after filtering for correctness

-    const nodes: ServiceNode[] = serviceNames
-      .map((name, i) => {
-        const stats = serviceMap.get(name)
-        if (!stats) return null
-        const angle = (i / nodeCount) * 2 * Math.PI - Math.PI / 2
-
-        return {
-          id: name,
-          name,
-          spanCount: stats.spanCount,
-          totalDuration: stats.totalDuration,
-          errorCount: stats.errorCount,
-          x: centerX + radius * Math.cos(angle),
-          y: centerY + radius * Math.sin(angle),
-          color: getServiceColor(name),
-        }
-      })
-      .filter((n): n is ServiceNode => n !== null)
+    const validServices = serviceNames
+      .map((name) => ({ name, stats: serviceMap.get(name) }))
+      .filter((s): s is { name: string; stats: NonNullable<typeof s.stats> } => s.stats != null)
+
+    const nodes: ServiceNode[] = validServices.map(({ name, stats }, i) => {
+      const angle = (i / validServices.length) * 2 * Math.PI - Math.PI / 2
+      return {
+        id: name,
+        name,
+        spanCount: stats.spanCount,
+        totalDuration: stats.totalDuration,
+        errorCount: stats.errorCount,
+        x: centerX + radius * Math.cos(angle),
+        y: centerY + radius * Math.sin(angle),
+        color: getServiceColor(name),
+      }
+    })

Alternatively, since the null case is unreachable, you could simplify by using the non-null assertion (serviceMap.get(name)!) with a comment explaining the invariant—though the current defensive approach is reasonable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/traces/TraceMap.tsx` around lines
100 - 117, The angle calculation for nodes uses the pre-filter index i and
nodeCount which can produce gaps if any items are filtered out; update
TraceMap.tsx so angles are computed after filtering: first build the filtered
list of valid services (use serviceMap.get(name) to filter and produce a
ServiceNode-like partial), then map that filtered array with its own index to
compute angle using its length as the nodeCount, or alternatively assert
non-null with serviceMap.get(name)! and remove the defensive filter (add a
comment explaining the invariant). Ensure you update references to nodes,
serviceNames, nodeCount, and the angle computation to use the post-filter
array/length so layout evenly redistributes.

packages/console-frontend/src/components/filters/TimeRangeFilter.tsx (1)

318-330: Static ID could cause duplicate IDs if multiple instances are rendered.

The hardcoded id="time-range-start" will create invalid HTML if multiple TimeRangeFilter components are mounted simultaneously. Consider using React.useId() to generate unique IDs per instance.

♻️ Suggested fix using useId

Add to imports and component body:

-import { useCallback, useMemo, useState } from 'react'
+import { useCallback, useId, useMemo, useState } from 'react'

Inside the component:

 export function TimeRangeFilter({
   ...
 }: TimeRangeFilterProps) {
+  const id = useId()
   const [isOpen, setIsOpen] = useState(false)

Then use dynamic IDs:

-                    htmlFor="time-range-start"
+                    htmlFor={`${id}-start`}
                     ...
-                    id="time-range-start"
+                    id={`${id}-start`}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/filters/TimeRangeFilter.tsx` around
lines 318 - 330, The label/input pair in the TimeRangeFilter component uses a
hardcoded id ("time-range-start") which can collide when multiple instances
mount; import and call React.useId() (or useId from React) inside the
TimeRangeFilter component to create a unique base id (e.g., idBase = useId())
and replace the static id and htmlFor with a scoped id like `${idBase}-start`
(and similarly update any matching end input if present) so the Input's id and
the label's htmlFor remain unique per component instance while keeping the
existing value/onChange (customStart, setCustomStart) intact.

packages/console-frontend/src/api/config-provider.tsx (2)

38-44: Consider setting staleTime and reviewing retry behavior.

The config data is unlikely to change during a session. Setting staleTime: Infinity (or a large value) would prevent unnecessary refetches. Also, retry: true enables infinite retries—if that's intentional, it's fine; otherwise, consider a finite number like retry: 3.

Suggested configuration

   const { data: config, error } = useQuery({
     queryKey: ['console-config'],
     queryFn: fetchConsoleConfig,
     retry: true,
     retryDelay: 3000,
+    staleTime: Infinity,
   })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/api/config-provider.tsx` around lines 38 - 44,
The useQuery in ConfigProvider is currently missing a staleTime and uses retry:
true (infinite retries); update the query options in ConfigProvider (the
useQuery call) to set staleTime: Infinity (or a large ms value) to avoid
refetching session-static console config, and change retry from true to a finite
count such as retry: 3 (or an appropriate number) to prevent infinite retry
loops.

---

33-35: Side effect inside queryFn may cause unintended behavior.

Calling setConfig(data) inside the query function means it runs on every successful fetch, including refetches and retries. If the config module caches state, this is fine. However, if setConfig has side effects (e.g., triggering re-renders or persisting to storage), consider moving it to an onSuccess callback pattern or ensuring idempotency.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/api/config-provider.tsx` around lines 33 - 35,
The query function currently calls setConfig(data) after parsing the response,
causing side effects on every fetch/retry; move the state mutation out of the
query function and into an onSuccess callback (or the component/caller that
invokes useQuery) so the queryFn only returns the fetched ConsoleConfig and
setConfig is invoked once or guarded for idempotency; specifically, remove the
setConfig(data) call from the fetch logic in config-provider.tsx and instead
call setConfig from the useQuery onSuccess handler (or wrap setConfig to no-op
when the value is unchanged) so setConfig and any re-render/persistence side
effects are controlled.

packages/console-frontend/src/routes/traces.tsx (1)

284-317: Consider throttling resize updates with requestAnimationFrame.

The resize handler updates state on every mousemove event, which can fire many times per second and cause unnecessary re-renders. The WaterfallChart component uses RAF throttling for its resize logic.

Example throttling pattern

   useEffect(() => {
+    let rafId: number | null = null
     const onMouseMove = (e: MouseEvent) => {
       if (!isResizingRef.current) return
+      if (rafId !== null) return
+      rafId = requestAnimationFrame(() => {
+        rafId = null
+        if (!isResizingRef.current) return
         const dx = resizeStartRef.current.x - e.clientX
         // ... rest of logic
+      })
     }
     const onMouseUp = () => {
       if (isResizingRef.current) {
+        if (rafId !== null) {
+          cancelAnimationFrame(rafId)
+          rafId = null
+        }
         isResizingRef.current = null
         // ...
       }
     }
     // ...
+    return () => {
+      // ... cleanup
+      if (rafId !== null) cancelAnimationFrame(rafId)
+    }
   }, [])

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/traces.tsx` around lines 284 - 317, The
mousemove handler currently calls setPanelWidths on every event causing
excessive re-renders; throttle updates using requestAnimationFrame by adding an
RAF loop inside the useEffect: in onMouseMove (used with isResizingRef and
resizeStartRef) capture the desired width calculation (using clampPanelWidth,
PANEL_MIN_WIDTH, totalWidth, etc.) into a local "next" value and schedule a
single requestAnimationFrame to call setPanelWidths(trace/ span) if one isn’t
already pending; store the raf id in a ref so you can cancel it on cleanup and
when onMouseUp clears isResizingRef and cancels any pending RAF to avoid
orphaned frames.

packages/console-frontend/src/components/traces/WaterfallChart.tsx (1)

270-284: Use role="separator" instead of role="slider" for resize handles.

A resize handle is semantically a separator that can be moved, not a slider. The aria-orientation should also be "vertical" since dragging is horizontal but it separates content vertically.

Suggested fix

           <div
-            role="slider"
+            role="separator"
             aria-label="Resize span column"
-            aria-orientation="horizontal"
+            aria-orientation="vertical"
             aria-valuemin={150}
             aria-valuemax={600}
             aria-valuenow={spanColWidth}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/traces/WaterfallChart.tsx` around
lines 270 - 284, In WaterfallChart.tsx update the resize handle element: change
role="slider" to role="separator", set aria-orientation="vertical" (since it
separates columns), and remove the slider-specific attributes aria-valuemin,
aria-valuemax and aria-valuenow; keep tabIndex, the event handlers
(startColResize, onDoubleClick that calls setSpanColWidth(300)), title and
styling so keyboard/mouse accessibility is preserved.

packages/console-frontend/src/routes/functions.tsx (1)

226-229: Consider including HTTP status in the result.

The InvocationResult interface defines status?: number (line 30), but it's never populated when setting the result. If invokeFunctionApi returns a status code, consider including it for debugging purposes.

If status is available from the API

       dispatchInvocation({
         type: 'SET_RESULT',
-        result: { success: result.success, duration, data: result.data, error: result.error },
+        result: { success: result.success, status: result.status, duration, data: result.data, error: result.error },
       })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/functions.tsx` around lines 226 - 229,
The dispatchInvocation call that sets the invocation result is missing the HTTP
status field defined on InvocationResult; update the object passed to
dispatchInvocation (inside the function that calls invokeFunctionApi and
currently uses dispatchInvocation({ type: 'SET_RESULT', result: { success:
result.success, duration, data: result.data, error: result.error } })) to
include status (e.g., status: result.status or the response HTTP status returned
by invokeFunctionApi) so the SET_RESULT payload populates
InvocationResult.status for better debugging.

packages/console-frontend/src/routes/logs.tsx (1)

285-302: Consider resetting page to 1 when filters change.

When searchQuery or activeLevelFilters change, the filteredLogs array may shrink, but currentPage isn't reset. This can result in an empty page view if the user was on page 5 and the filtered results only have 2 pages.

Example fix using useEffect

+  // Reset to page 1 when filters change
+  useEffect(() => {
+    dispatchPagination({ type: 'SET_PAGE', payload: 1 })
+  }, [searchQuery, activeLevelFilters.size, timeRange, selectedSeverity])
+
   const filteredLogs = useMemo(() => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/logs.tsx` around lines 285 - 302, When
filters change the current page can become invalid; add an effect to reset
pagination by calling setCurrentPage(1) whenever searchQuery or
activeLevelFilters change. Implement a useEffect that depends on [searchQuery,
activeLevelFilters] (or [searchQuery, activeLevelFilters, logs] if you prefer)
and inside call setCurrentPage(1); reference the existing filteredLogs,
currentPage and setCurrentPage state variables in the file to locate where to
add the effect.

packages/console-frontend/src/routes/triggers.tsx (2)

467-467: Unused underscore variable in filter callback.

The underscore in Object.entries(queryParams).filter(([_, v]) => v) could be replaced with a more explicit pattern or use .filter(([, v]) => v) to avoid the unused variable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/triggers.tsx` at line 467, The filter
callback for building queryEntries uses an unused named variable `_` which is
unnecessary; update the Object.entries call that produces queryEntries to
destructure only the used second element (e.g., use ([, v]) or similar) so the
unused key is not declared, i.e., change Object.entries(queryParams).filter(([_,
v]) => v) to use the ignored-first-element pattern and keep the filter logic
(reference: queryEntries and queryParams).

---

155-176: Missing default case in triggersUiReducer.

Unlike httpRequestReducer and invokeReducer, the triggersUiReducer lacks a default case. While TypeScript's exhaustiveness checking should catch unhandled actions at compile time, adding a default return ensures runtime safety.

🔧 Proposed fix

     case 'SET_EVENT_PAYLOAD':
       return { ...state, eventPayload: action.payload }
+    default:
+      return state
   }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/triggers.tsx` around lines 155 - 176,
triggersUiReducer is missing a default branch so unrecognized action types can
return undefined at runtime; update the switch in function triggersUiReducer to
include a default case that returns the current state (e.g., return state) to
ensure runtime safety for unknown TriggersUiAction values, and optionally
include an exhaustive type guard (using a never/assertUnreachable pattern) if
you want compile-time checks in addition to the default return.

packages/console-frontend/src/components/traces/FlameGraph.tsx (3)

93-100: Self-time calculation may be incorrect for overlapping child spans.

The current algorithm sums all children's durations and subtracts from parent duration. This assumes children execute sequentially without overlap. For concurrent/parallel spans, this could produce incorrect (potentially negative, though clamped to 0) self-time values.

If children can overlap in time, consider computing self-time based on actual time intervals rather than summing durations.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/traces/FlameGraph.tsx` around lines
93 - 100, The self-time logic for FlameGraph is wrong for overlapping children:
instead of summing child durations in the loop over spanMap.values(), compute
the total covered time by merging child time intervals (use each
child.span.start_ms and child.span.duration_ms to form [start,end), clamp those
intervals to the parent span bounds, sort and merge overlapping intervals to get
the union length), then set node.selfTime = Math.max(0, node.span.duration_ms -
coveredUnionLength). Update the block that currently accumulates
childrenDuration to perform interval clipping/merging for node.children and
subtract the merged coverage from node.span.duration_ms.

---

427-435: Wheel panning also lacks upper bound check.

Similar to minimap click, horizontal panning via wheel has no maximum bound, allowing users to pan past the content.

🔧 Proposed fix

     } else {
-      dispatch({ type: 'SET_PAN', panOffset: Math.max(0, panOffset + e.deltaY) })
+      const container = containerRef.current
+      if (!container) return
+      const width = container.clientWidth
+      const graphWidth = (width - PADDING * 2) * zoomLevel
+      const maxOffset = Math.max(0, graphWidth - (width - PADDING * 2))
+      dispatch({ type: 'SET_PAN', panOffset: Math.max(0, Math.min(maxOffset, panOffset + e.deltaY)) })
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/traces/FlameGraph.tsx` around lines
427 - 435, handleWheel allows panOffset to grow without an upper bound; clamp
the new pan value before dispatching SET_PAN. In handleWheel, compute the
maximum allowable pan (e.g. maxPan = Math.max(0, totalContentWidth -
viewportWidth) or call the existing getMaxPan helper if present), then replace
Math.max(0, panOffset + e.deltaY) with a clamped value like Math.min(maxPan,
Math.max(0, panOffset + e.deltaY)) and dispatch that clamped value for 'SET_PAN'
so horizontal wheel panning cannot move past the content.

---

437-451: Minimap click panning could exceed valid bounds.

The newOffset calculation can produce values that pan beyond the graph's content when clicking near the edges of the minimap. While Math.max(0, newOffset) prevents negative values, there's no upper bound check.

🔧 Proposed fix to add upper bound

     // Center viewport on click position
     const clickPercent = (clickX - PADDING) / (width - PADDING * 2)
     const newOffset = clickPercent * graphWidth - (width - PADDING * 2) / 2
-    dispatch({ type: 'SET_PAN', panOffset: Math.max(0, newOffset) })
+    const maxOffset = graphWidth - (width - PADDING * 2)
+    dispatch({ type: 'SET_PAN', panOffset: Math.max(0, Math.min(maxOffset, newOffset)) })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/components/traces/FlameGraph.tsx` around lines
437 - 451, The minimap click handler (handleMinimapClick) currently only clamps
negative pan values but can exceed the maximum scrollable range; compute the
viewportWidth as (width - PADDING * 2), compute graphWidth as already done, then
compute maxOffset = Math.max(0, graphWidth - viewportWidth) and clamp newOffset
into [0, maxOffset] before dispatching SET_PAN via dispatch({ type: 'SET_PAN',
panOffset: clampedOffset }); use existing minimapRef, containerRef, PADDING and
zoomLevel symbols to locate the values to compute the clamp.

packages/console-frontend/src/routes/streams.tsx (1)

130-192: Consider extracting a MAX_MESSAGES constant.

The 1000 cap is a magic number inside the reducer; a named constant makes it easier to tune and reuse.

♻️ Suggested refactor

+const MAX_MESSAGES = 1000
+
 function messagesReducer(state: MessagesState, action: MessagesAction): MessagesState {
   switch (action.type) {
     case 'add_message': {
       const { entry } = action
       return {
-        messages: [entry, ...state.messages].slice(0, 1000),
+        messages: [entry, ...state.messages].slice(0, MAX_MESSAGES),
         stats: {
           ...state.stats,
           totalMessages: state.stats.totalMessages + 1,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/console-frontend/src/routes/streams.tsx` around lines 130 - 192,
Introduce a named constant MAX_MESSAGES (e.g., const MAX_MESSAGES = 1000) near
the top of this module and replace the hard-coded 1000 in messagesReducer (the
.slice(0, 1000) call) with MAX_MESSAGES; ensure any future uses (if needed)
reference MAX_MESSAGES and keep INITIAL_MESSAGES_STATE unchanged, exporting
MAX_MESSAGES if it needs to be reused elsewhere.