query_graph: multi-key ORDER BY silently drops LIMIT (6326 rows / 117 KB instead of 5) on v0.9.1-rc.1

[b1rdex]

Version: v0.9.1-rc.1 (built from the tag, 560ad40, macOS arm64)
Tool: query_graph

Summary

A LIMIT is silently ignored when the query has an ORDER BY with more than one sort key. Single-key ORDER BY … LIMIT works; adding a second key makes the whole result set come back.

This is a token-safety problem rather than a cosmetic one: on a 24k-node graph my first natural hot-path query returned 6339 rows / ~587 KB (~147k tokens) into an agent's context instead of the 8 rows I asked for. On a bigger graph that is a context-window wipeout from a query that looks completely ordinary.

Reproduction

Same project, same binary, same DB — only the ORDER BY arity changes.

P=my-project

# A) single-key ORDER BY + LIMIT 5  -> correct
cbm cli query_graph --project $P \
  --query 'MATCH (f:Method) WHERE f.file_path STARTS WITH "src/" RETURN f.name ORDER BY f.complexity DESC LIMIT 5'
# rows: 5      (113 bytes)

# B) two-key ORDER BY + LIMIT 5     -> LIMIT DROPPED
cbm cli query_graph --project $P \
  --query 'MATCH (f:Method) WHERE f.file_path STARTS WITH "src/" RETURN f.name ORDER BY f.complexity DESC, f.name DESC LIMIT 5'
# rows: 6326   (117277 bytes)   <-- expected 5

# C) LIMIT 5, no ORDER BY          -> correct
cbm cli query_graph --project $P \
  --query 'MATCH (f:Method) WHERE f.file_path STARTS WITH "src/" RETURN f.name LIMIT 5'
# rows: 5      (113 bytes)

# D) two-key ORDER BY + LIMIT 5, plus the MCP-level guard -> correct
cbm cli query_graph --project $P --max-rows 5 \
  --query 'MATCH (f:Method) WHERE f.file_path STARTS WITH "src/" RETURN f.name ORDER BY f.complexity DESC, f.name DESC LIMIT 5'
# rows: 5      (113 bytes)

case	ORDER BY keys	LIMIT	rows returned	bytes
A	1	5	5	113
B	2	5	6326	117277
C	0	5	5	113
D	2	5 + max_rows:5	5	113

The original query that surfaced it (six projected columns, two sort keys, LIMIT 8) returned 6339 rows / 586541 bytes.

Notes

• max_rows is an effective workaround, which suggests the row cap is applied at the MCP layer and the planner simply loses the LIMIT node when the ORDER BY key list has length > 1.
• Since max_rows is optional and LIMIT is the documented, idiomatic way to bound a Cypher result, the failure mode is "agent writes a textbook query, gets a context flood".
• Possibly the same execution-order area as the closed Cypher: DISTINCT applied after ORDER BY + LIMIT instead of before (execution order bug) #237 / query_graph: RETURN DISTINCT … ORDER BY … LIMIT still under-returns on v0.8.1 (regression / incomplete fix for #237) #873 (DISTINCT vs ORDER BY … LIMIT), but this one needs no DISTINCT and over-returns rather than under-returns.
• Suggested belt-and-braces fix regardless of the parser bug: have query_graph fall back to a default max_rows when the query text contains a LIMIT that the planner did not honour, or log a cypher.limit.dropped warning.

Secondary, same call surface

toFloat() is rejected inside WHERE, though the README lists it under supported functions:

$ cbm cli query_graph --project $P \
    --query 'MATCH (a)-[r:CALLS]->(b) WHERE toFloat(r.confidence) < 0.4 RETURN count(r)'
unsupported function 'toFloat' in WHERE (supported: coalesce, substring, replace, left, right)

It does work in RETURN. Same shape as the closed #874 (coalesce() in WHERE), so the WHERE evaluator seems to support a much narrower function set than RETURN — worth either widening it or narrowing the documented list, because numeric comparison on edge properties like r.confidence (stored as a string) is otherwise impossible in WHERE.