fix(logs): split summary/detail contracts to make trace tab gate type-safe

[waleedlatif1]

Summary

The Trace tab was silently missing from the Log Details sidepanel because list and detail rows shared one WorkflowLog type with executionData: z.unknown(). The UI couldn't distinguish a summary row (no spans) from a detail row (with spans), so the tab gate read undefined and hid itself.

• Splits into WorkflowLogSummary (list) and WorkflowLogDetail (typed executionData with optional traceSpans) — makes the bug structurally impossible.
• Detail and new by-execution routes both write through to the same logKeys.detail(id) cache, eliminating two-key fragmentation that caused the merge memo workaround.
• List route moves to cursor pagination on (sortValue, id) with proper NULLS LAST handling and SQL-side sort across workflow + job execution tables (replaces in-memory merge that dropped rows under filters).
• Detail route now requires and asserts workspaceId. Deep-link path uses useLogByExecutionId instead of auto-paginating the entire workspace.

Test plan

• Open Logs page, click any workflow execution → Trace tab appears with correct data
• Navigate via arrow keys 10× rapidly → no flicker, no missing tabs
• Right-click a row → preview snapshot → sidebar still shows correct selected log
• Deep-link ?executionId=<id> → resolves in one round-trip, sidebar opens with detail (even for off-page logs)
• Sort by cost → server returns sorted results across all pages; Load more works
• Filter by status=error → page 2 contains correct rows
• Cancel a running execution → one mutation, invalidates lists() + detail(id), no stats refetch
• Cross-workspace test: deep-link to ?executionId=<id from other workspace> → 404

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 4, 2026 10:28pm

[cursor]

PR Summary

Medium Risk
Moderate risk because it changes the GET /api/logs response shape and pagination semantics (cursor + server-side sorting), adds a new API route, and threads required workspaceId through detail fetches, which can break callers and subtly affect ordering/filtering.

Overview
Fixes log detail rendering by splitting list vs detail types: WorkflowLogSummary for list rows and WorkflowLogDetail with typed executionData (including optional traceSpans) for the sidebar/embedded views, making Trace-tab gating type-safe.

Refactors the logs API surface: GET /api/logs now returns summaries with cursor-based pagination (nextCursor) and server-side sorting by date/duration/cost/status (with NULLS LAST) across workflow + job logs; log detail endpoints now require workspaceId, share a new fetchLogDetail loader, and add GET /api/logs/by-execution/[executionId] for deep-links.

Updates client hooks and UI to match: useLogsList uses cursor paging + sort params, useLogDetail requires workspaceId, deep-linking resolves via useLogByExecutionId, and components switch to contract-driven types while improving Trace-tab/keyboard behavior and cache consistency.

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

[greptile-apps]

Greptile Summary

This PR fixes the missing Trace tab by splitting WorkflowLog into typed WorkflowLogSummary (list) and WorkflowLogDetail (with executionData) contracts, replaces offset pagination with cursor pagination using (sortValue, id) tiebreakers, and introduces a dedicated by-execution route for single-round-trip deep-link resolution. Arrow-key navigation for deep-linked logs and stats invalidation after cancel/retry are also fixed.

• The cross-table cursor ID tiebreaker (previously flagged) remains: cursor.id from the merged last row is applied to both workflowExecutionLogs.id and jobExecutionLogs.id, which are independent UUID sequences, silently dropping rows at page boundaries.
• initializeFromURL() is now called inside a useState lazy initializer, a render-phase side effect that React Strict Mode will double-invoke.

Confidence Score: 3/5

Not safe to merge — the unfixed cross-table cursor tiebreaker causes silent row drops on page 2+ when workflow and job logs are mixed, and the new render-phase side effect risks double-initializing filter state in Strict Mode.

Two P1 findings: the previously flagged cross-table cursor UUID tiebreaker is still present (confirmed not addressed in this diff), and the new useState render-phase side effect for initializeFromURL. Multiple P1s on a core data-fetching path pull the score below the 4/5 P1 ceiling.

apps/sim/app/api/logs/route.ts (cursor tiebreaker), apps/sim/app/workspace/[workspaceId]/logs/logs.tsx (useState side effect)

Important Files Changed

Filename	Overview
apps/sim/lib/api/contracts/logs.ts	Core contract split: WorkflowLog → WorkflowLogSummary + WorkflowLogDetail; adds cursor-pagination response schema, typed executionData, and new by-execution contract. Well-structured.
apps/sim/app/api/logs/route.ts	List route rebuilt with cursor pagination and SQL-side sort; cross-table cursor ID tiebreaker (previously flagged P1) remains unfixed — cursor from one table is applied as tiebreaker to the other table's UUID column.
apps/sim/lib/logs/fetch-log-detail.ts	New shared loader for detail routes; queries workflow then job tables with proper permission checks, correctly transforms result to WorkflowLogDetail shape.
apps/sim/hooks/queries/logs.ts	Migrated to cursor pagination, split detail/summary types, added workspaceId to useLogDetail; stats and detail invalidations are correctly added back to cancel/retry mutations.
apps/sim/app/workspace/[workspaceId]/logs/logs.tsx	Deep-link resolution moved to useLogByExecutionId (cleaner); effectiveSidebarOpen and hasNext correctly guard the deep-link case; uses render-phase side effect in useState initializer (new P1).
apps/sim/app/workspace/[workspaceId]/logs/components/log-details/log-details.tsx	showTraceTab gate fixed — now shows optimistically on any execution log and displays loading/empty states; onActiveTabChange wrapped in useCallback; useLayoutEffect used correctly.
apps/sim/app/api/logs/[id]/route.ts	Simplified to use shared fetchLogDetail utility; now requires workspaceId for workspace-scoped 404 on cross-workspace access.
apps/sim/app/api/logs/by-execution/[executionId]/route.ts	New dedicated route for deep-link resolution; delegates to shared fetchLogDetail with executionId lookup; correct auth and workspace scoping.

Sequence Diagram

sequenceDiagram
    participant UI as Logs UI
    participant ListAPI as GET /api/logs
    participant DetailAPI as GET /api/logs/[id]
    participant ByExecAPI as GET /api/logs/by-execution/[id]
    participant DB as Database

    Note over UI: Normal page load
    UI->>ListAPI: workspaceId + filters + sortBy/sortOrder
    ListAPI->>DB: workflow UNION job (cursor paginated, SQL-sorted)
    DB-->>ListAPI: WorkflowLogSummary[] + nextCursor
    ListAPI-->>UI: { data, nextCursor }

    Note over UI: User clicks a row
    UI->>DetailAPI: logId + workspaceId
    DetailAPI->>DB: fetchLogDetail(id)
    DB-->>DetailAPI: WorkflowLogDetail (with executionData)
    DetailAPI-->>UI: { data: WorkflowLogDetail }
    UI-->>UI: setQueryData(logKeys.detail(id), data)

    Note over UI: Deep-link ?executionId=X
    UI->>ByExecAPI: executionId + workspaceId
    ByExecAPI->>DB: fetchLogDetail(executionId)
    DB-->>ByExecAPI: WorkflowLogDetail
    ByExecAPI-->>UI: { data: WorkflowLogDetail }
    UI-->>UI: setQueryData(logKeys.detail(data.id), data)
    UI-->>UI: dispatch TOGGLE_LOG → sidebar opens

Loading

Comments Outside Diff (1)

1. apps/sim/app/workspace/[workspaceId]/logs/logs.tsx, line 516-520 (link)

   Render-phase side effect via useState initializer

   initializeFromURL() is called inside a useState lazy initializer, which runs during the render phase. React treats render as a pure operation; side effects here can cause unexpected behaviour. In React Strict Mode, the lazy initializer is invoked twice on mount — initializeFromURL() would parse the URL and write to the Zustand store a second time. If the function is not idempotent (e.g. it appends or merges rather than replaces), this would corrupt the filter state on the first render. Even if it is idempotent today, the pattern is fragile.

   The original useEffect + isInitialized.current guard ran once after mount and is the safe pattern for one-time initialization with side effects.

_{Reviews (8): Last reviewed commit: "fix(logs): sync active-tab callback befo..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[waleedlatif1]

@greptileai pushing back on both points after re-tracing the code:

P1 — cross-table UUID tiebreaker. Not a bug. The cursor { v, id } is applied to both tables with the same id < cursor.id (DESC) predicate, and the in-memory merge sorts by (v, id) using localeCompare. Because:

1. Both workflowExecutionLogs.id and jobExecutionLogs.id are canonical lowercase UUID strings — globally lex-comparable.
2. Postgres uuid-type byte comparison matches JS localeCompare on canonical UUIDs (hex digits + - preserve byte→string ordering).
3. The SQL filter and the JS merge use identical ordering.

…the predicate (v, id) < cursor is well-defined regardless of which table contributed the cursor row. Concrete trace: workflow W1=(10,'aaa'), job J1=(10,'111'). Page 1 emits W1, cursor=(10,'aaa'). Page 2 SQL on the job table: v=10 AND id < 'aaa' → matches J1 because '111' < 'aaa' (digit < letter in ASCII). No drop. The pattern that genuinely breaks (independent per-source pagination without a unifying boundary, à la combine-pagination's Framed Range Intersection) isn't what this route does — there's a single cursor predicate applied to both tables in one round-trip, then a merge of the bounded results.

P2 — URL hydration double-fetch. Not a bug. useState(() => { useFilterStore.getState().initializeFromURL(); return null }) runs during render, before useFilterStore(useShallow(...)) reads the filters in the same render. Zustand's set() is synchronous, so the selector observes the URL-derived values on the very first render. useLogsList fires once, with the correct filters. No extra request, no defaults flash.

If I'm missing something on either point, happy to dig in further — please point at the specific scenario that drops rows.

[greptile-apps]

Having read the full route.ts and logs.tsx, both pushbacks hold up.

P1 — Cross-table cursor: Your analysis is correct. buildCursorCondition constructs a composite (sortValue, id) predicate that is applied identically to both tables in the same round-trip. For your W1=(10,'aaa'), J1=(10,'111') example: the condition is (sortExpr = 10 AND id < 'aaa'), and since '111' < 'aaa' holds in both ASCII and JS localeCompare (digit code points 49–57 are below letter code points 97–102), J1 is correctly included on page 2. The inverse case also holds — a job row with id='zzz' would sort before the 'aaa' cursor row in the (10, id DESC) ordering, so it would have appeared on page 1 and the id < 'aaa' filter correctly excludes it from page 2. The global ordering is self-consistent.

P2 — URL hydration: Also correct. The useState initializer is a synchronous call that fires during the render phase, before the useFilterStore(useShallow(...)) call lower in the same function body. Because Zustand's set() is synchronous and mutates the store in-place, the useShallow selector reads the URL-derived state on the very first render. One fetch, correct filters from the start.

I'll withdraw both comments.

Tip: You can give me more context with [.greptile/rules.md](https://www.greptile.com/docs/code-review/custom-standards) so I get this right next time.

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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