Repository navigation
Cypher parser rejects zero-hop open range *0.. variable-length relationships #983
Description
Summary
The Cypher parser currently rejects zero-hop open-range variable-length relationship syntax like *0.., which is needed for official LDBC SNB Interactive IS2-style queries.
Environment used for repro:
- repo:
graphistry/pygraphistry - sha:
ebe7d0ae827d724a8779e123c3965ec723581015 - host runtime:
uv run python ...
Minimal repro
import pandas as pd
from graphistry.tests.test_compute import CGFull
g = CGFull().nodes(
pd.DataFrame({
'id': ['message', 'post'],
'label__Message': [True, False],
'label__Post': [False, True],
}),
'id',
).edges(
pd.DataFrame({
's': ['message'],
'd': ['post'],
'type': ['REPLY_OF'],
}),
's',
'd',
)
query = "MATCH (message:Message)-[:REPLY_OF*0..]->(post:Post) RETURN post.id AS postId"
print(g.gfql(query)._nodes)Observed behavior
This fails with:
GFQLSyntaxError [invalid-cypher-syntax] Invalid Cypher query syntax
Expected behavior
Either:
- parse and execute
*0..as standard zero-or-more syntax, or - fail fast with an explicit validation error that this syntax is intentionally unsupported.
Right now it looks like a parser-level syntax rejection.
Why this matters
SNB IS2 uses REPLY_OF*0.. so the same pattern can match either:
- a post directly, or
- a comment chain that eventually reaches a post
Without *0.., the official query text cannot be expressed directly.
Related
#973 explicitly leaves *0 / *0..n out of scope. This issue tracks that specific gap separately.
Activity
[-]Cypher parser rejects zero-hop open range variable-length relationships[/-][+]Cypher parser rejects zero-hop open range `*0..` variable-length relationships[/+]feat(cypher): support *0.. open-range variable-length relationships (#…
feat(cypher): support *0.. open-range variable-length relationships (#…
lmeyerov commentedon Mar 31, 2026
Another measured SNB manifestation from
pyg-benchon 2026-03-31:LDBC SNB Interactiveinteractive-complex-12(Expert search) still fails on direct Cypher with:The relevant official pattern is:
So the earlier improvement after
#984does not appear to fully close the zero-hop open-range family. The relationship-alternation form[:HAS_TYPE|IS_SUBCLASS_OF*0..]is still benchmark-blocking.Current measured status for
interactive-complex-12:partialvia local tag-class-expanded reply aggregation workaround under#880parser_gapunder#983fix(cypher): support bounded zero-min varlen relationships (*0..N) (#983
lmeyerov commentedon Apr 5, 2026
PR: #1064 — fixes
*0..Nbounded zero-min varlen relationships. One-line parser fix (<= 0→< 0in_rel_hops()) + guard inrel_range_exact()to keep*0rejected. RED→GREEN, full cypher suite passing.fix(cypher): support bounded zero-min varlen relationships (*0..N) (#983
fix(tests): amplify #983/#1047 coverage — bag semantics, partial-hit,…
test: Round 2 amplification + DRY for #983/#1047
fix(tests): #983/#1047 test amplification — bag semantics, partial-hi…
lmeyerov commentedon Apr 6, 2026
Follow-on test amplification and DRY for this fix landed in PR #1070 (squash-merged 2026-04-06):
*-1,*-5..10,*1..-3) now tested to raiseGFQLSyntaxErrorspecifically*0..1(seed + direct neighbors) and*0..100(large bound stops at graph depth) confirmed*0..0boundary behavior documented (parses, returns empty)match5-8(*0..0) was incorrectly taggedGFQLValidationErroron tck-gfql main; corrected tosuccess_wrong_rows