Commit 6ef3a3b
authored
fix: surface BufferExec input panics instead of silently truncating output (apache#23243)
## Which issue does this close?
Closes apache#23242.
## Rationale for this change
When the input to a `BufferExec` panics, the panic unwinds the
background producer task (`MemoryBufferedStream`), tokio catches it at
the task boundary, and the dropped sender looks like a clean
end-of-stream to the consumer. A panic isn't a `Result::Err`, so it also
skips the `batch_tx.send(Err(..))` path — the partition gets silently
truncated and the query returns partial results instead of failing. More
detail in apache#23242.
## What changes are included in this PR?
Catch the panic at the input poll inside `MemoryBufferedStream` and
forward it as a `DataFusionError` over the channel the consumer already
drains, so it propagates instead of being swallowed.
I went with surfacing it as an error rather than re-raising via
`join_unwind` (the way `RecordBatchReceiverStream` does), since the
consumer already handles `Some(Err(..))` and this fails only the query.
Happy to switch to a re-raise if that's preferred for consistency.
## Are these changes tested?
Yes — added `panic_in_input_is_propagated`, which feeds a stream that
panics partway through and asserts the buffered stream yields an error
instead of finishing cleanly.
## Are there any user-facing changes?
A query whose input panics under a `BufferExec` now fails with an error
instead of silently returning truncated results. No API changes.1 parent 01bf68c commit 6ef3a3b
1 file changed
Lines changed: 43 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
41 | 41 | | |
42 | 42 | | |
43 | 43 | | |
44 | | - | |
| 44 | + | |
45 | 45 | | |
46 | 46 | | |
| 47 | + | |
47 | 48 | | |
48 | 49 | | |
49 | 50 | | |
| |||
337 | 338 | | |
338 | 339 | | |
339 | 340 | | |
340 | | - | |
341 | | - | |
342 | | - | |
343 | | - | |
344 | | - | |
| 341 | + | |
| 342 | + | |
| 343 | + | |
| 344 | + | |
| 345 | + | |
| 346 | + | |
| 347 | + | |
| 348 | + | |
| 349 | + | |
| 350 | + | |
| 351 | + | |
| 352 | + | |
| 353 | + | |
| 354 | + | |
| 355 | + | |
| 356 | + | |
| 357 | + | |
| 358 | + | |
345 | 359 | | |
346 | 360 | | |
347 | 361 | | |
| |||
554 | 568 | | |
555 | 569 | | |
556 | 570 | | |
| 571 | + | |
| 572 | + | |
| 573 | + | |
| 574 | + | |
| 575 | + | |
| 576 | + | |
| 577 | + | |
| 578 | + | |
| 579 | + | |
| 580 | + | |
| 581 | + | |
| 582 | + | |
| 583 | + | |
| 584 | + | |
| 585 | + | |
| 586 | + | |
| 587 | + | |
| 588 | + | |
| 589 | + | |
| 590 | + | |
| 591 | + | |
| 592 | + | |
| 593 | + | |
557 | 594 | | |
558 | 595 | | |
559 | 596 | | |
| |||
0 commit comments