[GLUTEN-12013][VL] Fix bloom-filter bytes corruption on whole-stage AQE fallback

[brijrajk]

What changes are proposed in this pull request?

Fixes #12013

Root cause

When ExpandFallbackPolicy triggers a whole-stage AQE fallback it reverts to the plan captured before HeuristicTransform runs (i.e. before all pre-transform rewrites). This means the substitution performed by BloomFilterMightContainJointRewriteRule — replacing vanilla Spark's BloomFilterMightContain with VeloxBloomFilterMightContain — is silently undone in the fallback plan.

If Stage 0 (the bloom_filter_agg subquery) has already executed natively it has produced Velox-format bloom filter bytes. The vanilla BloomFilterMightContain in the fallen-back filter stage then calls BloomFilterImpl.readFrom() on those bytes, which throws:

java.io.IOException: Unexpected Bloom filter version number (16777217)

or causes a native assertion failure (kBloomFilterV1 == version) during the merge phase.

Fix

Register BloomFilterMightContainFallbackPatcher as a second fallback-policy pass (after ExpandFallbackPolicy) in VeloxRuleApi. The patcher walks the subtree of every FallbackNode and replaces any remaining BloomFilterMightContain inside FilterExec nodes with VeloxBloomFilterMightContain, so the JVM filter can continue to read Velox-format bytes via JNI even after the whole-stage fallback.

The patcher is guarded by requireBloomFilterAggMightContainJointFallback() so it is a no-op for backends that do not require joint fallback (e.g. ClickHouse).

Files changed

• BloomFilterMightContainFallbackPatcher.scala — New Rule[SparkPlan] that patches fallback plans
• VeloxRuleApi.scala — Registers the patcher as a second fallback-policy pass
• GlutenBloomFilterAggregateQuerySuite.scala — Regression test for the exact failure scenario

---

How was this patch tested?

A regression test "Test bloom_filter_agg whole-stage fallback does not corrupt bloom filter bytes" was added to GlutenBloomFilterAggregateQuerySuite (tagged Issue12013).

The test reproduces the precise failure path:

• COLUMNAR_FILTER_ENABLED = false — forces FilterExec to fall back (net transition cost = 2)
• COLUMNAR_WHOLESTAGE_FALLBACK_THRESHOLD = 2 — only the filter stage triggers whole-stage fallback via ExpandFallbackPolicy; the bloom_filter_agg subquery stages (inherent cost = 1 < threshold) continue to run natively and emit Velox-format bytes
• ANSI_ENABLED = false — Spark 4.0 enables ANSI by default, which causes ObjectHashAggregateExec to fail Gluten validation and raises the agg-stage transition cost above 1; disabling ANSI keeps the agg cost at 1 so only the filter falls back as intended

Without the fix the test fails with IOException: Unexpected Bloom filter version number (16777217). With the fix all 200,003 rows are returned correctly.

The test was run inside the gluten-dev Docker container against the gluten-ut/spark40 module:

Tests: succeeded 1, failed 0, canceled 0, ignored 0, pending 0
All tests passed.

---

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (claude-sonnet-4-6)

[github-actions]

Run Gluten Clickhouse CI on x86

[brijrajk]

Could a maintainer please remove the CORE label? All three changed files are Velox-backend-specific (backends-velox/ and gluten-ut/spark40/) — no common core code is touched. VELOX label only is correct. Thanks!