Skip to content

fix: unbreak CI — pyarrow 25 added binary_view compare kernels, tripping the strict-xfail canary#542

Closed
NickCrews wants to merge 1 commit into
duckdb:mainfrom
NickCrews:fix-pyarrow-canary
Closed

fix: unbreak CI — pyarrow 25 added binary_view compare kernels, tripping the strict-xfail canary#542
NickCrews wants to merge 1 commit into
duckdb:mainfrom
NickCrews:fix-pyarrow-canary

Conversation

@NickCrews

Copy link
Copy Markdown
Contributor

Problem

Every PR's CI currently fails with:

FAILED tests/fast/arrow/test_filter_pushdown.py::TestCanaries::test_pyarrow_gains_binary_view_filter_support - [XPASS(strict)] pyarrow does not yet implement binary_view filter compare kernels

(example run: https://github.com/duckdb/duckdb-python/actions/runs/29216913610, from #409 — unrelated to that PR's content)

CI installs the latest pyarrow at run time, and pyarrow 25.0.0 added binary_view compare kernels. The canary body only exercised scanner construction, which no longer raises, so the strict xfail XPASSes and fails CI for everyone. Same spirit as #541: unbreak CI on main.

What actually changed in pyarrow (verified empirically on 23.0.1, 24.0.0, 25.0.0)

pyarrow scanner(filter=binary_view ==) executing the scan
≤ 24.0.0 raises ArrowNotImplementedError ('equal' has no binary_view kernel) n/a
25.0.0 succeeds raises ArrowNotImplementedError ('array_filter' has no binary_view kernel)

So pyarrow's support is still only partial — a binary_view filter still cannot be executed end-to-end, and DuckDB's post-scan fallback for view types (covered by TestUnsupportedTypes) is still required. (string_view is unchanged: even scanner construction still raises on 25.0.0.)

Fix

  • test_pyarrow_gains_binary_view_filter_support is converted from a strict xfail into a version-gated assertion (using the file's existing packaging.version.Version convention):

    • pyarrow < 25: scanner construction must raise ArrowNotImplementedError
    • pyarrow ≥ 25: scanner construction must succeed, and executing the scan must raise ArrowNotImplementedError

    Either branch failing means pyarrow moved again, preserving the canary's purpose: it fires when pyarrow gains full binary_view filter support and the post-scan fallback should be removed.

  • The sibling string_view canary keeps its strict xfail but now also executes the scanner, so when pyarrow lands string_view compare kernels ahead of filter kernels (as just happened for binary_view), it will keep xfailing instead of breaking CI again; it only xpasses on full end-to-end support.

Verification

  • Full tests/fast/arrow/test_filter_pushdown.py with pyarrow 23.0.1 (the repo's minimum for Python ≥ 3.10): 541 passed, 7 xfailed.
  • TestCanaries + TestUnsupportedTypes with pyarrow 25.0.0: 10 passed, 7 xfailed — the view-type post-scan fallback still yields correct results on latest pyarrow.
  • ruff check / ruff format --check clean.

Judgment call: rather than simply widening the xfail, the ≥ 25 branch pins down the new partial-support behaviour (construction works, execution doesn't), which documents exactly where pyarrow stands and what the fallback still protects against.

🤖 Generated with Claude Code

PR CI installs the latest pyarrow, and pyarrow 25.0.0 added binary_view
compare kernels. The strict-xfail canary
TestCanaries::test_pyarrow_gains_binary_view_filter_support only
exercised scanner construction, so it now XPASSes and fails CI for
every PR.

pyarrow's support is still only partial: the scanner can be built, but
executing it raises ArrowNotImplementedError because 'array_filter' has
no binary_view kernel. So DuckDB's post-scan fallback for view types is
still required. The canary is converted to a version-gated assertion:

* pyarrow < 25: scanner construction raises ArrowNotImplementedError
* pyarrow >= 25: scanner construction succeeds, execution raises

Either branch failing means pyarrow moved again and we should revisit
the fallback in TestUnsupportedTypes.

The sibling string_view canary (unchanged behavior through pyarrow 25)
now executes the scanner as well, so it will only fire on full
end-to-end support instead of breaking CI when compare kernels land
without filter kernels.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@NickCrews
NickCrews marked this pull request as draft July 13, 2026 03:11
@NickCrews

Copy link
Copy Markdown
Contributor Author

closing because I think #543 might be the real fix here? Anyway, this was generated by claude and I don't think I fully understand it, so I can't really verify this is the right direction, and don't want to waste maintainers time with slop.

@NickCrews NickCrews closed this Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant