Behaviour
Ranking a binding that a traversal introduces depends on the order the match block declares its bindings. With the ranked binding declared first, the query answers; declared after the binding it is reached from, it fails:
query q() { match { $p: Person { name: "p1" } $p knows $d } return { $d.slug } order { bm25($d.body, "needle") } limit 1 }
The same failure was reported twice from real graph work: a passage search scoped by a matter and its revisions, and a semantic search over the neighbours of one node selected by its key.
Mechanism
The compiler's lowering roots each traversal-connected component at its first-declared binding (crates/omnigraph-compiler/src/ir/lower.rs, scan_root, which prefers a searched binding only inside a correlated block). Only the root gets a scan, and ranking runs on a scan, so a ranked binding that is not the root has nowhere to run. Issue #750's filter half was fixed on engine v2 by #760; this is its ranking half.
Expected
Declaration order is not semantics. The ranked binding roots its component on both engines, so these queries answer regardless of order. On engine v2 the planner may also start from a selective other end (one key-selected node) and rank only the rows the traversal reaches. Only rrf arms on two bindings of one component stay refused, as a typed bad request. Tracked in RFC 0047 (#791, rollout step 4).
Behaviour
Ranking a binding that a traversal introduces depends on the order the
matchblock declares its bindings. With the ranked binding declared first, the query answers; declared after the binding it is reached from, it fails:search-ordered query produced rows without its 'd._score' ranking column.The same failure was reported twice from real graph work: a passage search scoped by a matter and its revisions, and a semantic search over the neighbours of one node selected by its key.
Mechanism
The compiler's lowering roots each traversal-connected component at its first-declared binding (
crates/omnigraph-compiler/src/ir/lower.rs,scan_root, which prefers a searched binding only inside a correlated block). Only the root gets a scan, and ranking runs on a scan, so a ranked binding that is not the root has nowhere to run. Issue #750's filter half was fixed on engine v2 by #760; this is its ranking half.Expected
Declaration order is not semantics. The ranked binding roots its component on both engines, so these queries answer regardless of order. On engine v2 the planner may also start from a selective other end (one key-selected node) and rank only the rows the traversal reaches. Only
rrfarms on two bindings of one component stay refused, as a typed bad request. Tracked in RFC 0047 (#791, rollout step 4).