feat(mcp): render paths results in the query-results UI app#61331
Merged
Conversation
Paths query results previously hit the "visualization not supported" state in the query-results UI app. Add a PathsVisualizer that renders the edge list as a table — parsing the `<stepIndex>_<value>` node keys into a step transition and path, sorting by user count, and formatting the average conversion time. Wired into the Component dispatch by both result-shape detection and the PathsQuery kind fallback. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
MCP UI Apps size report
|
Contributor
Prompt To Fix All With AIFix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
services/mcp/src/ui-apps/components/PathsVisualizer.tsx:20
**Unused `query` prop**
`PathsVisualizerProps` includes `query: PathsQuery | undefined`, and `Component.tsx` always passes it, but the component destructures only `results` and never reads `query`. The `PathsQuery` type does carry useful context (`startPoint`, `endPoint`, `includeEventTypes`) that other visualizers actively use (e.g., `RetentionVisualizer` reads `query.retentionFilter.*` to control chart behaviour), but none of it is consumed here. Either use the prop or drop it from the interface and the call site to avoid the dead parameter.
Reviews (1): Last reviewed commit: "feat(mcp): render paths results in the q..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
|
Size Change: 0 B Total Size: 81.1 MB ℹ️ View Unchanged
|
Addresses Greptile review: PathsVisualizer never read the `query` prop, so remove it from the props type and the call site rather than threading dead context through. The "Open in PostHog" link is unaffected — it is built from `_posthogUrl` by AppWrapper, not from the query prop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Paths query results had no visualization in the
query-resultsMCP UI app — they fell through to the "this visualization type isn't supported" state, leaving the agent/user with only the raw text table.Changes
Add a
PathsVisualizerto thequery-resultsapp. It renders the paths edge list as a table:<stepIndex>_<value>node keys into a step transition (1 → 2) and the path.average_conversion_time(ms) as1d 3h/34m 43svia a newformatDurationutil.N path transitions · busiest carries X users.Wired into the
Componentdispatch by both result-shape detection (source/target/valueguard) and thePathsQuerykind fallback, matching the existing visualizers. No YAML/generated changes —query-resultsis an existing custom app.It's a structured table, not a Sankey graph — the UI-app chart kit has no flow primitive and chart visualizers are owned separately.
How did you test this code?
Agent-authored. Ran
pnpm typecheck(pass) and built the UI apps locally. Verified end-to-end against a local instance: the paths query (hedgebox demo data) now renders the Paths table in the connected MCP client instead of the unsupported-state card.🤖 Agent context
Authored with Claude Code (Opus 4.8). Follow-up to the
query-paths-actorstool (already merged). Kept scope to the visualizer; a dev-only asset cache-bust explored during testing was dropped from this change.