Repository navigation
UI: Right-side call relationship panel is capped at 25 entries, hiding data for complex nodes #1198
Description
What problem does this solve?
The right-side call relationship panel currently limits the display to 25 entries by default. For nodes with
complex call graphs, this cap prevents users from seeing the full set of relationships.
Proposed solution
- Option A: Remove the 25-entry limit entirely, showing all call relationships by default.
- Option B: Keep the default limit but add a "click to expand" / "load more" bar at the bottom so users can reveal
additional entries on demand. - Option C: Implement both — remove the hard cap and add pagination/expand for very large datasets.
Alternatives considered
No response
Confirmations
- I searched existing issues and this is not a duplicate.
Activity
DeusData commentedon Jul 25, 2026
Thanks for the report, and for laying out three concrete options rather than just the complaint — that makes the decision much easier to reason about.
Confirmed on
main, with one refinement worth knowing: the cap is per relationship-type group, not per panel. It lives atgraph-ui/src/components/NodeDetailPanel.tsx:225:which sits inside the
groups.map(([type, conns]) => …)loop at line 219. So a node with, say,CALLS,CALLED_BYandIMPORTSrelationships gets up to 25 rows of each, not 25 rows total. For a hot node with 400 callers, you are seeing 25 of them undercallswhile the other groups render independently.Two things already work in your favour, which narrows what actually needs building:
{title} <span>({count})</span>(line 217) — so the real degree is not hidden.+N moreline whenconns.length > 25, so the truncation is signposted rather than silent. It just is not actionable.That last point makes Option B cheaper than it looks: the affordance and its count already exist and render in the right place; what is missing is making that line a control rather than a label. Option A worries me for the opposite reason — the panel is rendered inside the graph view, and nodes in large repos can reach four-figure degree, so an uncapped list is a scroll and layout problem rather than a rendering one.
Which of the three we take is a product call rather than a triage one, so I am not going to pre-commit here. Recording it as a well-specified enhancement with the groundwork above; the "+N more" line being one step from the answer is the useful finding.
Thanks for flagging it precisely enough that the fix surface is now a single component.
feat(ui): CBM Atlas region scene, deep links, sidebar selection, unca…