-
Notifications
You must be signed in to change notification settings - Fork 3.5k
max_nodes truncation ignores node importance #2129
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or requestpriority/normalStandard review queue; useful PR with ordinary maintainer urgency.Standard review queue; useful PR with ordinary maintainer urgency.ux/behaviorDisplay bugs, docs, adoption UXDisplay bugs, docs, adoption UX
Description
Activity
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestpriority/normalStandard review queue; useful PR with ordinary maintainer urgency.Standard review queue; useful PR with ordinary maintainer urgency.ux/behaviorDisplay bugs, docs, adoption UXDisplay bugs, docs, adoption UX
Severity: medium.
GET /api/layout?max_nodes=5000returns 514 edges out of ~179 000. Nodes appearto be selected in id order rather than ranked, so the budget is spent on leaves.
Before excluding generated JSON it was 164 edges; removing ~4 600 noise nodes moved
it only to 514 — so ranking, not noise, is the binding constraint.
Ask: rank by (non-builtin) degree and status (
entry,exported) when truncating.Observed on v0.10.8 (build
996bad5fe6fb), macOS arm64, Python monorepo (~36k nodes / ~179k edges). Happy to provide a minimal reproduction repo if useful.