GFQL: two-hop count returns a STALE answer after in-place frame mutation (degree-count memo setattrs onto the caller's Plottable, keyed by id() — the BLOCKER-1 pattern the same file forbids)

[lmeyerov]

Summary

_two_hop_cached_equal_domain_degree_counts caches degree frames by setattr-ing onto the caller's Plottable, keyed by id(nodes_obj)/id(edges_obj). After an in-place mutation of the caller's node/edge frame, the next gfql() on the same Plottable returns the stale answer, silently.

This is the exact failure the same file warns against, five times, forty lines above (gfql_fast_paths.py:206-208, and at :245, :282, :319, :373):

"Per-execution cache only (threaded via cache_store); NEVER setattr onto the caller's Plottable -- that leaked results across gfql() calls keyed by id(), returning stale answers after an in-place edge/node mutation (BLOCKER 1)."

_two_hop_cached_equal_domain_degree_counts (gfql_fast_paths.py:490) does precisely that.

Reproduction — verified on origin/master 1537e4676

dgx-spark, graphistry/test-rapids-official:26.02-gfql-polars, --gpus all, master tree mounted read-only. Query is the canonical two-hop count (equal node domains, equal edge match):

Q = ("MATCH (a {node_type:'Person'})-[{rel:'FOLLOWS'}]->(b {node_type:'Person'})"
     "-[{rel:'FOLLOWS'}]->(d {node_type:'Person'}) RETURN count(*) AS numPaths")

nodes = pd.DataFrame({"id":[0,1,2,3], "node_type":["Person"]*4})
edges = pd.DataFrame({"src":[0,1,1], "dst":[1,2,3], "rel":["FOLLOWS"]*3})
g = graphistry.nodes(nodes,"id").edges(edges,"src","dst")

g.gfql(Q)                      # -> 2   (correct)
edges.loc[2,"rel"] = "BLOCKS"  # in-place: edge 1->3 is no longer FOLLOWS
g.gfql(Q)                      # -> 2   *** WRONG, expected 1 ***

graphistry.nodes(nodes,"id").edges(edges,"src","dst").gfql(Q)   # -> 1  (ground truth)

Engagement is asserted, not assumed — the memo helper was instrumented, and the run records memo_called=3, memo_HIT=1 (a genuine cache hit, not a coincidental value match):

engine	memo called / HIT	before	after in-place mutation	fresh Plottable, same frames
polars	3 / 1	2	2	1
pandas	3 / 1	2	2	1
polars-gpu	3 / 1	2	2	1

All engines, not just polars — there are two call sites in _execute_two_hop_count_fast_path, one in the POLARS_ENGINES branch (:1910) and one in the else arm (:1960).

Why id() keying cannot work here

id() is stable across in-place mutation (the object is the same; only its contents changed) and is reused after garbage collection. So the key is simultaneously too coarse (misses mutation) and unsound (a new frame can inherit a dead frame's id and collide). The sibling caches avoid both by threading a per-execution cache_store instead of attaching to the caller.

Fix

Bring it to BLOCKER-1 parity: make it a per-execution cache threaded through cache_store rather than setattr onto base_graph.

Disclosure — this fix has a benchmark cost, and that should be stated up front

The cross-call memo is what makes the graph-benchmark q8 cell fast. Measured on dgx (RAPIDS 26.02, --gpus all, perf lock, RUNS=31, position-balanced, values identical across arms):

scale	q8 with warm memo	q8 with memo disabled
20k	2.11 / 2.32 ms	11.98 ms
100k	5.31 / 5.77 ms	53.84 ms

And the memo only pays off when a Plottable is reused across calls, which the benchmark harness does but ordinary one-shot use does not:

	q8 reused Plottable	q8 fresh Plottable	Kuzu, same session
20k	2.31 – 2.74 ms	14.23 – 21.54 ms	2.79 – 4.22 ms
100k	5.60 – 5.87 ms	52.79 – 53.59 ms	9.37 – 17.72 ms

So q8's published win is 6–9× better in the harness than the same query issued one-shot, and one-shot it is a 4–6× loss rather than a win. (q9 is mode-insensitive by contrast — 39.7 vs 39.0 ms at 100k — so that cell transfers.)

Fixing this correctness bug will cost q8 its board cell. That is the correct trade: a cached wrong answer is not a performance feature. Filing it explicitly so the number moves for a stated reason rather than quietly.

Related

• GFQL: Cypher OLAP fast paths silently run on CPU under engine='polars-gpu' (bare LazyFrame.collect() bypasses the GPU-or-error contract) #1824 — same family of fast-path/framework-bypass defects
• The q8 board cell should be re-measured one-shot or footnoted regardless of when this is fixed.

[lmeyerov]

Independently confirmed, and the obvious confound is now ruled out

The original measurement compared a reused Plottable against a fresh one — but a fresh Plottable also re-binds 2.4M edges, so that gap could have been API overhead rather than the memo. Re-ran with two extra arms that decompose it:

• reused_cold — same Plottable, memo attribute delattr'd before each call → memo miss, no bind cost
• bind_only — bind, no gfql() → bind cost alone

dgx-spark, graphistry/test-rapids-official:26.02-gfql-polars, --gpus all, perf lock, runs=21, warmup=5. Master build verified byte-identical to origin/master (gfql_fast_paths.py md5 a55996d642432a7be5373965de3ecd2e).

scale	arm	q8 median	q9 median
20k	reused_warm	2.02 ms	17.41
20k	reused_cold	13.18 ms	18.38
20k	fresh	14.60 ms	19.87
20k	bind_only	0.02 ms	0.04
100k	reused_warm	5.09 / 5.28 ms	75.78 / 75.64
100k	reused_cold	49.68 / 56.15 ms	73.99 / 70.45
100k	fresh	53.02 / 55.57 ms	65.98 / 67.45
100k	bind_only	0.02 / 0.04 ms	0.04

Bind is free (0.02–0.04 ms), so the confound is dead. And reused_cold ≈ fresh at both scales — that's the positive identification: the gap is the memo and nothing else. Engagement asserted rather than assumed: memo_n=1 for q8, memo_n=0 for q9.

Values identical across all four arms at both scales (q8: 1999405 / 58431994; q9: 1017900 / 45562239), so the ratios are quotable.

What this means for the two cells

• q8 warm vs cold: 6.5–7.2× at 20k, 9.4–10.9× at 100k. Against same-session Kuzu (2.79–4.22 ms at 20k, 9.37–17.72 at 100k), one-shot GFQL loses 3.1–5.2× at 20k and 2.8–6.0× at 100k. q8 is a loss in ordinary use, at both scales.
• q9 is mode-insensitive — 17.41 warm vs 19.87 fresh at 20k; 75.78 vs 65.98 at 100k, where fresh is faster, i.e. pure noise. q9's win is a genuine per-call work reduction and transfers.

So the trade in the fix stands as stated: repairing this costs q8 its cell, and q8's cell was measuring a cache hit. q9 is the number to stand behind.

[lmeyerov]

Reopening: this was closed as completed, but the code is unchanged on master.

gfql_fast_paths.py:516-526 on master 99c14975806b46541dc497a2807c149b6fe2d6cd still reads:

cache_attr = "_gfql_two_hop_equal_domain_degree_counts_cache"
cache = getattr(base_graph, cache_attr, None)
if not isinstance(cache, dict):
    cache = {}
    try:
        setattr(base_graph, cache_attr, cache)
    ...
full_key = (id(nodes_obj), id(edges_obj), engine.value, ...)

That is exactly what this issue reported — a cross-call cache stamped onto the caller's Plottable, keyed by id(), so an in-place frame mutation silently yields a stale answer. It is still reachable from both call sites (:2422 and :2472).

The issue was auto-closed by merge commit 6a27684154f067a5b0f9b616ebf82cdf7595f871, whose own body states: "This PR neither causes nor fixes #1825." That commit widened the memo-MISS branch; it never touched the memo.

The benchmark side of this is now measured, and it is worse than the disclosure assumed

pyg-bench #121 added a cold-binding arm to the harness (a fresh Plottable per timed iteration over the same already-materialized frames; engine conversion stays untimed in both arms, so only the binding moves). dgx-spark, perf lock, RUNS=51, 4 slots per arm, position-balanced, values byte-identical across arms:

scale	Kuzu	GFQL-polars warm	GFQL-polars cold
20k	2.64 ms	1.71 ms — 1.55× win	8.89 ms — 0.30× LOSS
100k	9.29 ms	5.15 ms — 1.80× win	34.11 ms — 0.27× LOSS

Controls: q9 — same two hops plus two range filters, but the distinct-domain fused lane, which has no memo — is mode-insensitive and wins in both arms (1.31×/1.18× at 20k, 2.38×/2.29× at 100k). A bind-only control costs 0.02 ms, so the 6.6× penalty is real recomputation, not the rebinding. pandas moves the same way and loses in both arms.

There is a fix that is both correct and faster than the memo ever was

Removing the memo naively leaves q8 at 29 ms of recomputation. Two plan-shape alternatives were measured and both refuted:

variant @100k
two chained semi-joins (master)	29.19 ms
one filter, two is_in	32.86 ms — worse
project [src,dst] first	28.58 ms — ~2%
aggregation floor, no membership test at all	13.28 ms — already loses to Kuzu's 9.29 ms
degree counts materialized once, project+sum	0.23 ms

So no plan-shape change can win this, and the last row is the answer: hold the degree counts on the edge index, built once and untimed — symmetric with Kuzu's own untimed COPY/index build, and already modelled by the benchmark lane's --index all slots. Query-time work drops from 29 ms to 0.23 ms, and there is then no reason for a cross-call cache to exist at all, which closes this correctness bug by deletion rather than by rework.

Raw data: results/graphbench-q8-binding-20260729/ in pyg-bench.