query_graph: patterns with no label on the source node silently return empty — same DB and binary previously returned correct rows (v0.9.0)

[junk151516]

Environment: v0.9.0, Windows amd64 (ui variant), same index DB as #1110 / #1132 / #1133 (10 projects; main graph 31k nodes / 176k edges, 43,851 CALLS edges per get_graph_schema). The CLI and the MCP server return identical results. First mentioned in #1110 (comment) — filing it on its own as it's unrelated to the (invalid) direction flag discussed there.

Summary: On 2026-07-15 this query returned 2 correct rows (documented verbatim in #1110's body):

MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'auto_match' RETURN a.qualified_name   → 2 rows (correct)

Today, same binary (SHA-pinned) and same project, it returns {"rows":[],"total":0} with the generic no-results hint. Probe matrix:

Query shape	Result
MATCH (n) RETURN n.name	✅ rows
MATCH (n) WHERE n.name = '<existing>' RETURN ...	❌ silent empty
MATCH (n) WHERE n.lines > 100 RETURN ...	❌ silent empty
MATCH (n:Method) WHERE n.name = '<same>' RETURN ...	✅ 1 row
MATCH (a)-[r]->(b) RETURN a.name (untyped edge)	✅ rows
MATCH (a)-[r:CALLS]->(b) RETURN a.name	❌ silent empty
MATCH (a:Function)-[r:CALLS]->(b) RETURN a.name, b.name	✅ rows
MATCH (a:Function)-[r:CALLS]->(b) WHERE b.name = 'X' RETURN ...	✅ correct callers (verified vs grep)
MATCH (a)-[r:CALLS]->(b:Method) WHERE b.name = 'X' RETURN ...	❌ silent empty (label on the TARGET doesn't help)

Reproduced identically on a second project in the same DB (13.5k nodes), for string and numeric predicates, via both the CLI and the MCP server.

What changed between "worked" (2026-07-15) and "broken" (2026-07-21): not the binary. The DB went through several delete_project + fresh-index cycles (projects added and removed on 2026-07-16) plus incremental auto-watch updates. It looks like whatever powers unlabeled scans / typed-edge anchor selection consults per-label state that goes stale after those cycles, while label-anchored plans still read the live data.

Impact: the most natural Cypher an LLM agent emits (MATCH (a)-[:CALLS]->(b) WHERE b.name = ...) now silently reads as "no callers" — the same confidently-wrong-empty failure family as #1111 / #1133. Workaround: always put a label on the pattern's source node.

Asks:

1. Make unlabeled matching consistent with label-anchored matching after delete/reindex cycles (or rebuild the relevant index on write).
2. Until then, fail explicit: if the planner resolves a zero-cardinality anchor while the schema reports non-empty labels/edge types, return an error or a diagnostic instead of a clean empty set.

Happy to run a diagnostic build against this DB — it's private, but I can run anything read-only and share the output.

[DeusData]

Thanks for the probe matrix and same-binary/same-database timeline. This is a high-priority 0.9.1-rc silent-wrong-result bug under #594. Review will compare unlabeled and source-labelled plans across delete, full rebuild, and incremental cycles, and must fail loudly rather than return a clean empty result when planner metadata disagrees with live graph cardinality.

[Enferlain]

Confirmed independently on current dev, Linux x64, with both OVERRIDE and INHERITS. This is not limited to CALLS, Windows, an old persisted database, or delete/incremental-update cycles.

I created a standalone synthetic Python repository and indexed the completed fixture once under a brand-new project name with mode="full":

project: cbm-query-consistency-fresh
3,652 nodes / 5,896 edges
Method: 1,698
Class: 1,698
OVERRIDE: 248
INHERITS: 248
generation_matches: true
parse_partial: 0
skipped: 0

The relevant tail of the fixture is ordinary direct inheritance:

class VeryLateBase:
    def dispatch(self) -> str:
        return "base"

class VeryLateAlpha(VeryLateBase):
    def dispatch(self) -> str:
        return "alpha"

class VeryLateBeta(VeryLateBase):
    def dispatch(self) -> str:
        return "beta"

The file also contains 1,200 unrelated classes with one unrelated method each, generated before these classes. A smaller control with 495 Method nodes returned consistent results; after increasing the unrelated method-source population to 1,698, the unlabeled-source plan failed.

OVERRIDE matrix

trace_path proves the two relationships are traversable:

{
  "function_name": "cbm-query-consistency-fresh.zz_pressure.VeryLateBase.dispatch",
  "direction": "inbound",
  "depth": 1,
  "edge_types": ["OVERRIDE"],
  "include_tests": true,
  "mode": "calls"
}

Actual: callers_total=2 (VeryLateAlpha.dispatch, VeryLateBeta.dispatch).

Equivalent unlabeled-source Cypher silently returns zero:

MATCH (a)-[:OVERRIDE]->(b)
WHERE b.qualified_name = 'cbm-query-consistency-fresh.zz_pressure.VeryLateBase.dispatch'
RETURN a.qualified_name, b.qualified_name

Adding the label to the source returns the correct two rows:

MATCH (a:Method)-[:OVERRIDE]->(b)
WHERE b.qualified_name = 'cbm-query-consistency-fresh.zz_pressure.VeryLateBase.dispatch'
RETURN a.qualified_name, b.qualified_name

Adding the label only to the target still returns zero:

MATCH (a)-[:OVERRIDE]->(b:Method)
WHERE b.qualified_name = 'cbm-query-consistency-fresh.zz_pressure.VeryLateBase.dispatch'
RETURN a.qualified_name, b.qualified_name

Broad counts show the same failure:

MATCH (a)-[r:OVERRIDE]->(b) RETURN COUNT(r)                  -> 0 rows
MATCH (a:Method)-[r:OVERRIDE]->(b:Method) RETURN COUNT(r)    -> 248
get_graph_schema OVERRIDE count                              -> 248

INHERITS matrix

The equivalent unlabeled query for VeryLateBase returns zero, while the source-labelled query returns both children and trace_path(edge_types=["INHERITS"]) reaches the base.

Broad counts are incomplete rather than wholly empty:

MATCH (a)-[r:INHERITS]->(b) RETURN COUNT(r)                -> 244
MATCH (a:Class)-[r:INHERITS]->(b:Class) RETURN COUNT(r)    -> 248
get_graph_schema INHERITS count                            -> 248

All fixture paths have matching current coverage metadata with no recorded gaps.

Interpretation

This evidence points to a scale/order-sensitive source-candidate enumeration or query-planning defect for unlabeled source nodes. It does not look like different graph stores, generations, or edge-name normalization: get_graph_schema, source-labelled query_graph, and trace_path all agree on the same freshly indexed relationships. The safe workaround remains to label the pattern's source node explicitly.

[junk151516]

Original reporter here. @Enferlain's independent repro holds on our side, and chasing it across nine real indexed repositories turned up what looks like the actual mechanism. The trigger is the row limit, not scale and not the label itself. Scale is a symptom.

The limit is applied to source-candidate enumeration, before predicate filtering

With no label on the source node, max_rows appears to bound how many candidate source nodes get scanned, rather than how many result rows get returned. The predicate is then evaluated only over that truncated prefix. A label lets the scan start from the label index, so the budget is never spent on unrelated nodes.

Same query, same database, same binary (v0.9.0, Windows), only --max-rows varies:

project: kumo-app  (11,619 Function / 3,201 Method / 43,851 CALLS)
query:   MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'resolveSedeId' RETURN a.qualified_name
truth:   103   (COUNT(r) with no --max-rows flag)

--max-rows      unlabeled source      MATCH (a:Function)...
    50                   0                  50   (correctly capped)
   103                   0                 103
   200                   0                 103
   500                   0                 103
   600                   0                 103
   800                   0                 103
  1000                   0                 103
  1500                  10                 103
  2000                  36                 103
  2500                  88                 103
  3000                  93                 103
  4000                 103                 103
  5000                 103                 103
 (no flag)             103                 103

The unlabeled result climbs monotonically with the limit until it saturates at the true value. It is not a binary empty/non-empty failure — the limit is buying visibility into more of the candidate space.

Reproduced on a second repository:

project: webIA  (4,228 Function / 10,816 CALLS)
query:   MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'str' RETURN a.qualified_name
truth:   1,048 total  (965 of them from Function)

--max-rows      unlabeled       a:Function
   100               0             100   (correctly capped)
   500             113             500   (correctly capped)
  1000             729             965
  2000           1,048             965
  8000           1,048             965

Note the contrast in the same table: with the label, --max-rows behaves exactly as documented — it caps the output. Without it, it silently truncates the search.

This accounts for every earlier observation

• Scale sensitivity (495 methods fine, 1,698 broken) — a larger unrelated node population pushes the matching nodes past the enumeration budget. Nothing about the graph changed; the budget stopped reaching them.
• Order sensitivity — your fixture generates 1,200 unrelated classes before the relevant ones. That is precisely a scan-prefix effect: the unrelated nodes are enumerated first and exhaust the budget.
• Partial rather than empty results (your INHERITS 244 of 248, our webIA 113 of 1,048) — a partially-consumed budget yields a partial answer, which is the dangerous case: a plausible number that is quietly wrong.
• Broad COUNT(r) with no limit being correct — we verified this across all nine projects; unlabeled MATCH (a)-[r:CALLS]->(b) RETURN COUNT(r) matched get_graph_schema exactly every time, including kumo-app at 43,851 edges. No truncation, no bug.
• Why small repositories look healthy — seven of our projects (up to 886 Function nodes / 1,704 CALLS) return correct unlabeled results at limits that break the two large ones. Their entire node population fits inside the budget.

A falsifiable check

If this reading is right, your existing 1,698-method fixture should return the correct two rows for the unlabeled OVERRIDE query without any re-indexing, purely by raising max_rows well above the node population. And the 495-method control should be made to fail by lowering it. That would confirm the defect is in limit placement rather than in planning or enumeration correctness, and it would move the fix from the planner to wherever the row budget is bound.

This is black-box inference — we have not read the source, so treat the mechanism as a hypothesis and the measurements as the evidence.

Practical note

The safe workaround is unchanged, but worth restating precisely: label the source node. Raising max_rows above the candidate population also works, but it is not a workaround anyone can apply safely — you cannot know the right value without already knowing the graph size, and being wrong fails silently.

The corollary matters more than the workaround: an unlabeled-source query carrying a limit cannot be trusted at all, including for counts. It does not merely risk returning nothing; it can return a well-formed, believable subset. We have updated our internal query recipes to forbid the shape outright rather than treat empty results as the only failure signal.

Happy to run further probes on these graphs — they are real codebases spanning 232 to 43,851 CALLS edges, which makes the threshold easy to bracket.

[DeusData]

Thanks @Enferlain and @junk151516 for the independent fixture and the max_rows sweep. The new diagnosis is confirmed by current main.

scan_pattern_nodes uses max_rows to cap an unlabeled source scan (src/cypher/cypher.c:3016-3026), and execute_single passes that same value into source enumeration before WHERE filtering (cypher.c:4636-4646). The public header, however, defines max_rows as an output-row limit. That is exactly the pre-filter truncation your monotonic table demonstrates.

This remains priority/high in 0.9.1-rc. The acceptance test needs both directions: raising max_rows restores the late matches without reindexing, and lowering it can hide them while the labeled-source query remains correct. Thank you for turning a scale symptom into a falsifiable root cause.