A search-ordered aggregate applies no order, so limit keeps arbitrary groups

[ragnorc]

Behaviour

A query whose return aggregates and whose order leads with a search function applies no order at all, so limit keeps an arbitrary set of groups. On engine v2:

set engine = v2;
query q() { match { $d: Doc } return { $d.rank, count($d) as n } order { bm25($d.body, "needle"), $d.rank desc } limit 3 }

returned the groups rank 1, 3 and 4 over four rows with ranks 1 to 4; the keys ask for 4, 3, 2. Engine v1 behaves the same way (exec/query.rs: "Aggregated search-ordered queries keep the historical no-sort behavior").

Mechanism

• optimizer.rs sort_keys returns None when a ranking sits under an Aggregate, so the trailing keys are dropped together with the score key.
• The GQT runner refuses expect ordered for any aggregate return, noting that "a search-led aggregate query is not ordered at all".

Expected

The leading search function selects the population the aggregate reads (the matches, or the nearest window), and the remaining order keys order the group rows, bound against return as the shared expression model specifies for order keys; the group keys break remaining ties so limit is deterministic. A query with no key after the search function keeps an unordered result, stated as such.

Tracked in RFC 0047 (#791, rollout step 5). Today the nearest window under an aggregate is the query's limit, which there counts groups; RFC 0048 (#793) makes that window an explicit candidates: option.