Repository navigation
gfql polars-gpu: the fused grouped-aggregate lane and the polars-gpu strictness tests fail on the RAPIDS 26.02 image (plan not GPU-executable on its cudf-polars) #2064
Description
Real-GPU lane on dgx-spark, image graphistry/test-rapids-official:26.02-gfql-polars (cudf 26.02.01, cupy 13.6.0, polars 1.35.2), TEST_CUDF=1, suites test_chain.py / test_hop.py / test_chain_alias_column_collision.py / tests/compute/gfql/**. At master 86de0f5: 13227 passed / 93 failed / 47 xfailed / 4 xpassed. The same 93 fail at the #2056 and #2060 heads (set difference vs master empty), so this is an image/runtime capability gap, not a branch effect:
tests/compute/gfql/cypher/test_grouped_aggregate_fused_polars.py(matches_eager_twin_and_pandas ×71, serves_total_order_shapes ×8, serves_the_graph_benchmark_shapes ×2, places_nulls_the_opencypher_way ×2): onengine='polars-gpu'the fused lane raisesNotImplementedError: GFQL engine='polars-gpu': this query plan is not fully GPU-executable on the installed cudf-polars (NO-CHEATING: we raise rather than silently run it on CPU …)where the tests expect the lane to serve.tests/compute/gfql/test_strictness_levels.pypolars-gpu cases (absent_return_property_is_null ×2, warns_once, strict_absent_names_raise, quiet_emits_no_warning): same decline.
These pins never run in CI (#1890: polars-gpu executes in no CI lane), so the dgx receipt is the only place they show. Either the fused lane declines to the CPU polars plan on this cudf-polars (typed decline, tests adjusted to expect it on that runtime) or the plan is made GPU-executable; until then every real-GPU receipt carries these 93 as the known baseline.
Activity
lmeyerov commentedon Sep 6, 2026
Root cause, from dumping the failing frame's plan at the lane's collect on dgx: the fused single-hop grouped-aggregate lane's low-cardinality
count(*)alternative lowers tocol(key).value_counts()+UNNEST, and cudf-polars 26.02 raisesNotImplementedError: Unhandled map function unnest._run_fast_path_on_requested_targetturns any NotImplementedError on the GPU target into "declined; plan not GPU-executable, generic route answers", so the generic route answered with the right values and the pins failed on served-by only. Not a dtype problem and not a pre-check false positive on our side (theInvalid type_idtext belongs to the strictness cases below).Fix: #2066 keeps the
group_by(...).agg(pl.len())formulation on the GPU target (cudf-polars executes it; verified on the engine). GPU receipt on the two files: 607 passed / 5 failed at the fix vs 520 / 91 on master.Remaining on this issue:
test_strictness_levels.pypolars-gpu cases (MATCH (n) RETURN n.nope_col AS c, 5 pins). They fail on the CPU polars engine too (polars engine does not yet natively support cypher row op 'select'), and once that path runs, the absent-property placeholder ingfql_unified.py:340is an untypedpl.lit(None)that cudf-polars rejects (Null dtype has no libcudf type_id;pl.lit(None).cast(<dtype>)is fine). So: polarsselectcapability first, then type that literal.fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
fix(gfql): the fused grouped-aggregate lane keeps the group_by plan o…
Merge pull request #2062 from graphistry/fix/gfql-2058-general-path-i…