Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

CI: extended tests don't run on changes to functions-aggregate / functions-window, which the aggregate and window fuzzers exercise

Aperta Adatta ai principianti
#24,212 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@shinzoxD ci sta già lavorando.

Dal 15/8/2026.

  • #24403 di @shinzoxD — aperta

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
88/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
github-actions, rust
Ambito
ci-cd

Direzione di ricerca

Inizia da .github/workflows/extended.yml e ispeziona il filtro dei percorsi esistente per il workflow extended-tests. Aggiungi la copertura per i percorsi dei due crate functions, quindi verifica la configurazione del workflow e conferma che le modifiche sotto questi percorsi attivino i test estesi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Is your feature request related to a problem or challenge?

The fuzz tests in datafusion/core/tests/fuzz_cases/ are gated behind the extended_tests feature, which only .github/workflows/extended.yml enables. On pull requests that workflow is limited to these paths:

paths:
  - 'datafusion/physical*/**/*.rs'
  - 'datafusion/expr*/**/*.rs'
  - 'datafusion/optimizer/**/*.rs'
  - 'datafusion/sql/**/*.rs'
  - 'datafusion-testing'

Two of the fuzzers exercise crates that aren't on that list:

  • aggregate_fuzz.rs builds queries with .with_aggregate_function(...) for min, max, sum, count, median, first_value, last_value — implemented in datafusion/functions-aggregate/.
  • window_fuzz.rs imports datafusion_functions_window and datafusion_functions_aggregate.

So a PR that changes an aggregate or window function implementation does not run the fuzz suite built to exercise it. It is still caught by the post-merge run on main, so this is a gating gap rather than missing coverage — the cost is a red main and a revert instead of a red PR.

A recent concrete case: #24104 "fix: support untyped NULL input for median" (merged 2026-08-09) changed datafusion/functions-aggregate/src/median.rs, and was itself fixing a regression between DataFusion 53 and 54. The workflows that ran on its head SHA were CodeQL, Dependencies, Detect breaking changes, Dev, Labeler, Large files PR check, and Rust; Datafusion extended tests did not run.

To be clear about what that does and doesn't show: aggregate_fuzz generates typed columns with a null percentage, whereas that bug involved an untyped NULL literal, so the fuzzer very likely would not have caught this particular issue. The point is narrower — a fuzzer-covered function was modified and its fuzzer didn't run.

Describe the solution you'd like

Add the two crates the fuzzers actually import:

  - 'datafusion/functions-aggregate/**/*.rs'
  - 'datafusion/functions-window/**/*.rs'

Measured cost. Over the last 50 merged PRs, 2 (4%) would newly trigger the workflow. On a recent main run (31366139826) the three jobs run in parallel: sqlite suite 9m32s, extended_tests 9m21s, hash collisions 5m20s — about 9.5 minutes wall-clock, ~24 runner-minutes.

I deliberately kept datasource* and catalog* out of this proposal even though some fuzz modules import them: 9 of the 12 unfiltered PRs in that sample were datasource*, and six were a single one-off refactor(proto): migrate <X>Source serde batch, so including them would raise the trigger rate to ~24% for what looks like a temporary campaign.

Describe alternatives you've considered

  1. Per-job path conditions — put the wider path set on linux-test-extended only, leaving the sqlite and hash-collision jobs on the current narrow trigger. Same wall-clock, but ~9 runner-minutes instead of ~24. More surgical, slightly more complex than a two-line paths addition.
  2. Do nothing. Post-merge detection on main may already be the intended trade-off, given that #19228's motivation for extended_tests was local developer inner-loop speed rather than CI cost. If that's the case it would be useful to have it stated, since the path list reads as a deliberate "most likely to trigger errors" selection.

Additional context

Verified locally at 308e212: cargo test -p datafusion --features extended_tests --profile ci --test fuzz --no-run takes 2m09s cold, and all 114 fuzz tests pass in 4m48s (--test-threads=4). aggregate_fuzz is 10 tests, window_fuzz is 2; together they run in 39.6s. So the two fuzzers relevant here are a small fraction of the suite.

I'm happy to open a PR for whichever option you prefer.

Lingua principale
Rust
Stelle
9.4k
Fork
2.5k
Merge medio
3g 16h
PR unite (30g)
372

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/datafusion

Tutte le issue di apache/datafusion

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.