Fix WeightedNeighbors queue growth

[vndee]

Summary

• replace the re-enqueueing weighted neighbor traversal with a bounded hop-layer frontier
• keep the best score per node while preserving hop-limited semantics
• add regression coverage for the shorter-path expansion case under a hop cap

Validation

• go test ./internal/graph
• go test ./...
• go vet ./...

Closes #2

Summary by CodeRabbit

• Refactor

  • Optimized internal graph traversal algorithm to improve efficiency of weighted path computation across constrained distances

• Tests

  • Added test coverage for weighted path scenarios where multiple routes to a node exist, validating correct weight selection and multi-hop expansion behavior

[coderabbitai]

📝 Walkthrough

Walkthrough

The WeightedNeighbors algorithm was refactored from a queue-based BFS approach to a hop-structured frontier approach. Instead of re-enqueueing nodes whenever a better weight is found, the algorithm now processes nodes layer-by-layer (0 to maxHops-1), maintaining only the best cumulative weight per node within each hop frontier.

Changes

Cohort / File(s)	Summary
Algorithm Refactor internal/graph/graph.go	Replaced queue-based BFS with hop-structured frontier iteration. Nodes are now processed in layers by hop depth rather than being re-enqueued, eliminating unbounded queue growth. Per-node best weights are still tracked and updated globally, but intermediate hop state is no longer stored in a separate map.
Test Coverage internal/graph/graph_test.go	Added TestWeightedNeighbors_PreservesShorterPathForFurtherExpansion to verify that when multiple paths exist to a node within hop constraints, the stored weight is correctly used for downstream expansions.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 From queue-chaos to frontier dreams,
Hop by hop in structured beams,
No more re-enqueueing's endless spree,
Lighter, tighter, finally free! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix WeightedNeighbors queue growth' accurately captures the main change: replacing the unbounded queue re-enqueueing with a bounded hop-layer frontier approach to prevent quadratic queue growth.
Linked Issues check	✅ Passed	The implementation addresses issue #2 by replacing queue-based re-enqueueing with a hop-structured frontier approach that prevents unbounded queue growth, though it differs from the proposed max-heap solution.
Out of Scope Changes check	✅ Passed	All changes are scoped to the WeightedNeighbors traversal logic and its test coverage; no unrelated modifications or refactoring are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/issue-2-weighted-neighbors

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR fixes unbounded queue growth in Graph.WeightedNeighbors by changing the weighted traversal to a bounded, hop-layer frontier approach that preserves hop-limited expansion semantics, and adds a regression test covering the shorter-path expansion under a hop cap.

Changes:

• Replaced the re-enqueueing relaxation loop in WeightedNeighbors with a per-hop frontier (frontier → next) to bound work by maxHops.
• Updated WeightedNeighbors doc comment to describe the hop-layer semantics and why they matter for hop-limited reachability.
• Added a regression test ensuring a shorter (lower-weight) path can still enable further expansion within a hop budget.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/graph/graph.go	Refactors WeightedNeighbors to use bounded hop-layer frontiers and avoid unbounded re-enqueueing.
internal/graph/graph_test.go	Adds a regression test for preserving shorter-path expansion behavior under maxHops.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

🧹 Nitpick comments (1)

internal/graph/graph.go (1)

340-348: Make the non-negative weight contract explicit.

Keeping only the max score per node per hop is safe only if edge weights are non-negative. Edge.Weight/AddEdge still accept any float64, so this pruning can change results if a negative weight ever slips in. Please document or validate that invariant at the API boundary.

Also applies to: 363-375

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/graph/graph.go` around lines 340 - 348, Make the non-negative
edge-weight contract explicit by validating and/or documenting it at the API
boundary: ensure Edge.Weight and the graph mutation API (e.g., AddEdge) reject
or normalize negative float64 weights and/or add a clear comment in the public
API that weights must be non-negative; then update the traversal code
(WeightedNeighbors and the hop-limited pruning logic referenced around the
comment blocks) to either assert the invariant at start or handle negative
weights safely if you choose to allow them. Reference Edge.Weight, AddEdge, and
WeightedNeighbors when adding the validation/comment so future callers cannot
supply negative weights that would break the per-hop best-score pruning.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@internal/graph/graph.go`:
- Around line 340-348: Make the non-negative edge-weight contract explicit by
validating and/or documenting it at the API boundary: ensure Edge.Weight and the
graph mutation API (e.g., AddEdge) reject or normalize negative float64 weights
and/or add a clear comment in the public API that weights must be non-negative;
then update the traversal code (WeightedNeighbors and the hop-limited pruning
logic referenced around the comment blocks) to either assert the invariant at
start or handle negative weights safely if you choose to allow them. Reference
Edge.Weight, AddEdge, and WeightedNeighbors when adding the validation/comment
so future callers cannot supply negative weights that would break the per-hop
best-score pruning.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6f91c999-2861-4b8a-a3c3-25d4e7f9dcbb

📥 Commits

Reviewing files that changed from the base of the PR and between d64f6b4 and aee1d3c.

📒 Files selected for processing (2)

• internal/graph/graph.go
• internal/graph/graph_test.go