You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(facts): cap traversal output, not the BFS frontier (#157)
traverseFrom had two exclusion paths. The node-kind filter queues the node
it excludes so traversal continues through it; the maxNodes path did not,
so the BFS frontier died roughly one ply past the cap. Every node reachable
only through a capped-out node was silently missed, and NodesVisited /
MaxDepthReached — computed over that truncated walk — were reported as
properties of the graph.
Queue the node when the cap is hit, matching the kind-filter contract.
maxNodes now bounds the returned set only. Nodes already appended are
unaffected, so the result stays the BFS-order prefix of an uncapped walk.
This also repairs a fused statistic in the impact summary: the dependent
count came from an uncapped reachableCount while the depth printed beside
it came from the cut walk, so one sentence combined a complete count with
an incomplete depth. The comment documenting the frontier cut compensated
for the count only, and is corrected to match the new behaviour.
Measured on a 1.9M-fact graph: worst-case traversal 6ms -> 22ms. Extraction
output is unchanged — facts and insights are byte-identical across the
change, and no explainer calls traverseFrom — so no cacheVersion bump and
no golden regeneration.
Tests pin that the walk is cap-independent and that the returned set stays
the uncapped prefix. The branching fixture is load-bearing: a chain has one
successor per node and cannot detect sibling reordering.
0 commit comments