UI: Right-side call relationship panel is capped at 25 entries, hiding data for complex nodes

[Maystern]

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.

[DeusData]

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 at graph-ui/src/components/NodeDetailPanel.tsx:225:

{conns.slice(0, 25).map((c, i) => (

which sits inside the groups.map(([type, conns]) => …) loop at line 219. So a node with, say, CALLS, CALLED_BY and IMPORTS relationships gets up to 25 rows of each, not 25 rows total. For a hot node with 400 callers, you are seeing 25 of them under calls while the other groups render independently.

Two things already work in your favour, which narrows what actually needs building:

• The group header renders the true total — {title} <span>({count})</span> (line 217) — so the real degree is not hidden.
• Line 237-239 already renders a +N more line when conns.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.