Cypher/GFQL rejects multi-stage MATCH ... WITH ... MATCH ... WITH ... MATCH read queries

[lmeyerov]

Problem

Local Cypher/GFQL still has residual gaps on benchmark-relevant multi-stage MATCH ... WITH ... MATCH ... read queries.

Remaining residuals

1. IC3 residual lane: Cypher/GFQL: free-form intermediate MATCH after WITH (LDBC SNB IC3 endpoint) #1263
   • implementation split discovered during execution: Cypher/GFQL: free-form trailing WHERE bridge refs across carried + fresh aliases #1275 (free-form trailing WHERE bridge refs across carried + fresh aliases)
2. IC5 residual family (split from Cypher/GFQL: support multi-MATCH-source row projection in RETURN/WITH (IC5 residual from #999) #1257):
   • Cypher/GFQL: forward scalar carry columns through trailing WITH narrowing in reentry suffix (IC5 sub-residual A) #1272 runtime scalar carry forwarding
   • Cypher/GFQL: admit multi-MATCH-source row projection without hidden carries (IC5 sub-residual B) #1273 multi-source projection admits

Child Gates

• Cypher/GFQL: free-form intermediate MATCH after WITH (LDBC SNB IC3 endpoint) #1263 — IC3 endpoint lane
• Cypher/GFQL: forward scalar carry columns through trailing WITH narrowing in reentry suffix (IC5 sub-residual A) #1272 — IC5 sub-A
• Cypher/GFQL: admit multi-MATCH-source row projection without hidden carries (IC5 sub-residual B) #1273 — IC5 sub-B

Recent progress

• fix(cypher): point residual one-source rejection to #1273 #1274 merged: Cypher/GFQL: admit multi-MATCH-source row projection without hidden carries (IC5 sub-residual B) #1273 acceptance item for explicit reject-pointer landed

Related

• Cypher/GFQL: introduce a first-class row-carrier IR for multi-stage vectorized row semantics #989, Meta: benchmark coverage unlock plan for GFQL and GFQL/Cypher #992, Meta: GFQL compiler/planner post-M4 execution DAG (active wave) #1259, Meta: GFQL monolith shrinkdown (lowering.py + CompiledCypher cleanup) #1260, Meta: #1046 native type-system staged decomposition program #1262
• Cypher/GFQL: free-form trailing WHERE bridge refs across carried + fresh aliases #1275 (IC3 lane residual split discovered during Cypher/GFQL: free-form intermediate MATCH after WITH (LDBC SNB IC3 endpoint) #1263 implementation)

[lmeyerov]

Measured another benchmark manifestation of this lane on March 31, 2026: LDBC SNB Interactive interactive-complex-5 (new-groups).

Official query shape:

• MATCH (person)-[:KNOWS*1..2]-(friend)
• WITH DISTINCT friend
• MATCH (friend)<-[membership:HAS_MEMBER]-(forum)
• WITH forum, collect(friend) AS friends
• OPTIONAL MATCH (friend)<-[:HAS_CREATOR]-(post)<-[:CONTAINER_OF]-(forum)

Current measured behavior in pyg-bench against pinned master 7095102df and the staged official fixture:

• GFQL: partial via adapter workaround, expected rows matched
• direct Cypher: primitive_gap with GFQLSyntaxError: [invalid-cypher-syntax] Cypher WITH after post-WITH MATCH is not yet supported in the current GFQL Cypher compiler

This makes interactive-complex-5 the third measured SNB manifestation of #999 after interactive-complex-3 and the broader translation inventory predictions.

[lmeyerov]

Shipped in #1013 and released in v0.53.14 on 2026-04-01.\n\nCoverage added for bounded multi-stage reentry () with local + cuDF validation and CI green.

[lmeyerov]

Closure details: implemented via PR #1013 and released in v0.53.14 on 2026-04-01. Added bounded multi-stage reentry support for MATCH/WITH/MATCH/WITH/MATCH/RETURN shapes, with local + DGX cuDF validation and full CI green on merge + release commits.

[lmeyerov]

Fresh current-master benchmark repro from pyg-bench on 14dafaf6b951954d8de840f9236f3e874249ebac:

• official query: interactive-complex-5 / new-groups
• artifact: /home/lmeyerov/Work/pyg-bench/results/runs/dgx-spark-snb-interactive-ic5-origin-master-14dafaf6b9-fresh-r1
• GFQL: partial under #880
• direct Cypher: primitive_gap
• exact current error:

[invalid-cypher-syntax] Cypher WITH after post-WITH MATCH WHERE is not yet supported in the current GFQL Cypher compiler

So this lane is not benchmark-cleared on current master; reopening #999 is justified by a fresh official SNB repro, not just historical state.

[lmeyerov]

IC3 Measurement Update from pyg-bench

The pyg-bench SNB Interactive conformance harness now measures LDBC IC3 (interactive-complex-3.cypher, cross-country-messages primitive) against the Cypher backend. IC3 hits this issue directly:

Error observed:

[invalid-cypher-syntax] Cypher MATCH after WITH is only supported for alternating MATCH ... WITH ... MATCH ... [WITH ... MATCH ...] ... [WITH] RETURN read shapes

IC3 uses a MATCH ... WITH ... MATCH ... WITH ... MATCH ... RETURN shape with three MATCH stages and country-windowed message aggregation across them. It remains classified as primitive_gap in the harness, tracked here as graphistry/pygraphistry#999.

The pyg-bench probe for IC3 is classified under ISSUE_CYPHER_MULTI_STAGE_REENTRY in adapters/snb_interactive/runner.py.

[lmeyerov]

Fresh repro from current master — Path A / Path B split

Cut feat/999-multistage-reentry-rev2 from master@6891d39e4 on 2026-05-01 and built reduced repros (MATCH ... WITH ... MATCH ... WHERE ... WITH ... MATCH ... WHERE ... RETURN-shaped) against the existing _mk_multi_stage_reentry_graph ABCDE fixture.

What the reductions hit

The reductions do not trip the surface parser errors quoted in this issue. They fall through to deeper row-lowering invariants:

• IC3-shaped → graphistry/compute/gfql/cypher/lowering.py:7622 — "trailing MATCH must start from same carried node alias". The middle MATCH (b:B)-[:R]->(c:C) introduces aliases b/c that aren't carried; bounded-reentry assumes every reentry MATCH starts from the carried alias.
• IC5-shaped → graphistry/compute/gfql/cypher/lowering.py:1914 — "row lowering currently supports one MATCH source alias at a time". Returning values from two distinct MATCH sources in the same RETURN is rejected.

The literal alternating MATCH ... WITH ... MATCH and WITH after post-WITH MATCH WHERE strings reported in this issue come from the un-reduced LDBC IC3/IC5 queries (multi-pattern initial MATCH (a), (x:Country), (y:Country), KNOWS*1..2 varlen, chained trailing MATCH). Those parser surface gates (parser.py:1620 alternating-shape; parser.py:1591 post-WITH MATCH WITH) sit above the lowering invariants — passing them only exposes the deeper constraint.

Plan: Path A in this issue, Path B in #989

Path A — this lane (feat/999-multistage-reentry-rev2, draft PR forthcoming). Build a Person/Country LDBC-mini fixture, repro the literal issue errors, lift the parser surface gates for the supported read shapes, and execute vectorized for the cases that don't depend on the architectural constraints below. This keeps #999 moving and gives colleagues something measurable.

Path B — #989 (row-carrier IR). The carried-alias-only and single-MATCH-source-alias row-lowering constraints are the real exit gate for vectorized multi-stage reentry across the LDBC SNB benchmark family (IC3/IC5 and likely more). I'm adding a pointer comment to #989 with the concrete lowering.py line numbers so the row-carrier IR work can target them directly.

Steering note for parallel work

If anyone is touching lowering.py reentry paths, please coordinate via #989 rather than this issue — #999 is now scoped to the Path A surface lift only.

[lmeyerov]

Correction — literal IC3/IC5 queries don't trip parser surface gates either

Earlier comment framed Path A as a parser-surface lift. After running the literal IC3/IC5 queries from the issue body verbatim against an LDBC-mini Person/Country/City + Forum/Post fixture (plans/999-multistage-reentry-rev2/repro/repro_ldbc.py), they don't fire any parser gate. They fall straight through to the same row-lowering invariants:

• IC3 literal → graphistry/compute/gfql/cypher/lowering.py:7208
  "Cypher MATCH after WITH currently requires the prefix WITH stage to project exactly one whole-row alias". IC3 carries WITH a, x, y (Person + 2 Country aliases) — three whole-row aliases, not one.

• IC5 literal → graphistry/compute/gfql/cypher/lowering.py:1914 (multi-source-alias row lowering, same path as my reduced repro).

The alternating MATCH ... WITH ... MATCH parser error quoted in this issue can be triggered (existing test at test_lowering.py:7867 does so with M W M M RETURN), but it doesn't fire for either canonical LDBC query as written. The parser gates have been mostly cleared by prior work (#1013, #1023, #1043, #1047); what's left blocking the SNB family is row-carrier architecture.

Revised plan

There is no meaningful Path A surface lift for these specific LDBC queries — the smallest meaningful slice is lifting the single-whole-row prefix WITH constraint at lowering.py:7207-7213 to admit multi-whole-row carries (WITH a, x, y with all three carried into the trailing MATCH chain). That is bounded but it is row-carrier work and belongs in #989's scope.

Proposing to retarget this branch (feat/999-multistage-reentry-rev2) at:

1. Slice 1 — multi-whole-row prefix WITH carry. Lift lowering.py:7207 to admit N whole-row aliases when only one is reused as the trailing-MATCH source (the others carry through as bound row state). Tests: IC3-shaped positive on LDBC-mini; failfast on cross-alias trailing reentry that still isn't supported.

2. Slice 2 — multi-MATCH-source row projection (the IC5 blocker at lowering.py:1914). Larger; may merit its own PR. Defer decision until Slice 1 lands.

If that scoping looks wrong — e.g., if the row-carrier IR rewrite under #989 is imminent and Slice 1 should wait for it — say so and I'll park this branch. Otherwise I'll proceed with Slice 1 as the next concrete step on #999.