fix(cypher): two-MATCH reentry with connected varlen produces wrong rows (match5-25,26)

[lmeyerov]

Summary

TCK scenarios match5-25 and match5-26 use two separate MATCH clauses with connected variable-length patterns. After PR #995 removed the nonterminal varlen guard, these queries execute but produce wrong results instead of being rejected.

Repro

match5-25: MATCH (a:A) MATCH (a)-[:LIKES]->()-[:LIKES*3]->(c) RETURN c.name
match5-26: MATCH (a:A) MATCH (a)<-[:LIKES]-()-[:LIKES*3]->(c) RETURN c.name

These go through the reentry match path (two MATCH clauses), which is a different code path from the single connected pattern that PR #995 fixed.

Context

PR #995 correctly handles variable-length rels in single connected patterns via prune_to_endpoints. The reentry match path (query.reentry_matches) was not modified and may need similar pruning.

Related

• Cypher multihop: expand direct variable-length support beyond endpoint-only patterns #973: connected varlen patterns (single-pattern case fixed)
• fix: extend bounded cypher reentry carrier #975: bounded reentry carrier
• TCK xfail contract: match5-25,26 are marked success_wrong_rows

[lmeyerov]

Finding 001: #1001 does not reproduce as a product bug on valid graphs

Date

2026-04-01

Summary

The live sibling signal for #1001 (match5-25, match5-26 => success_wrong_rows) does not correspond to a current pygraphistry product bug on valid graphs.

Evidence

1. Live sibling contract still fails

On origin/master = d6e652ef5 (v0.53.15):

PYTHONDONTWRITEBYTECODE=1 \
PYGRAPHISTRY_PATH=/tmp/pygraphistry-two-match-varlen-reentry \
PYTHONPATH=/tmp/pygraphistry-two-match-varlen-reentry:. \
pytest -q tests/cypher_tck/test_tck_runner.py -k 'match5-25 or match5-26'

Observed:

• match5-25 -> success_wrong_rows
• match5-26 -> success_wrong_rows

2. Forward shape works on a valid deep graph

On a product-side binary tree deep enough for:

MATCH (a:A) MATCH (a)-[:LIKES]->()-[:LIKES*3]->(c) RETURN c.name

pygraphistry returns the expected 16 leaf names.

3. Reverse shape also works on a valid graph

On a product-side graph with:

• one incoming LIKES edge into a:A
• three outgoing LIKES hops from the same source node to c

both:

MATCH (a:A)<-[:LIKES]-()-[:LIKES*3]->(c) RETURN c.name
MATCH (a:A) MATCH (a)<-[:LIKES]-()-[:LIKES*3]->(c) RETURN c.name

return the expected endpoint rows.

4. The sibling fixture is missing the setup needed by the expected rows

The sibling scenario metadata for match5-25 / match5-26 expects rows like:

• n00000 ... n01111

but MATCH5_GRAPH in:

• /home/lmeyerov/Work/tck-gfql/tests/cypher_tck/scenarios/fixtures.py

contains only:

• 15 nodes
• 14 edges
• leaves only up to n0111

So the direct runner's simplified fixture does not contain the full setup implied by the scenario expectations.

5. The scenario reason text already hints at this

The sibling scenarios are currently marked xfail for reasons including unsupported setup expressions:

• match5-25: MATCH/CREATE setup expressions are not supported
• match5-26: MATCH/DELETE/CREATE setup are not supported

Conclusion

#1001 should not currently drive a pygraphistry product fix. The observed success_wrong_rows is a sibling contract/setup-fixture problem, not an honest local compiler wrong-answer repro on valid graphs.

Recommended next action

One of:

1. close or re-scope pygraphistry#1001
2. move the remaining work to tck-gfql contract/setup handling
3. if someone still suspects a product bug, require a standalone in-repo graph fixture that reproduces it without relying on unsupported TCK setup expressions

[lmeyerov]

Landed via #1329 (merged).

What we shipped:

• Strengthened the existing two-MATCH reentry varlen acceptance test from shape-only (_nodes is not None) to exact expected rows
• Added forward split-vs-connected equivalence regression on a non-empty deep-tree fixture
• Added reverse split-vs-connected equivalence regression on a non-empty fixture

Result: This locks the match5-25/26 query family against wrong-row drift in local product behavior.

Issue closed as covered by merged regression hardening.