Skip to content

fix(arrow/flight/flightsql): drain channel in flightSqlServer.DoGet#437

Merged
zeroshade merged 1 commit intoapache:mainfrom
arnoldwakim:fix-issue-435
Jul 14, 2025
Merged

fix(arrow/flight/flightsql): drain channel in flightSqlServer.DoGet#437
zeroshade merged 1 commit intoapache:mainfrom
arnoldwakim:fix-issue-435

Conversation

@arnoldwakim
Copy link
Copy Markdown
Contributor

@arnoldwakim arnoldwakim commented Jul 14, 2025

Rationale for this change

This PR fixes #435.
If writing to the RecordWriter fails, the current implementation does not drain the channel when an error occurs while writing to the record writer.

What changes are included in this PR?

We add a deferred function that will drain the channel and call .Release() on the underlying StreamChunks in order to be able to release the RecordReader.

Are these changes tested?

@zeroshade as you suggested, I'll gladly accept a recommendation for the test setup.

Are there any user-facing changes?

No.

@arnoldwakim arnoldwakim requested a review from zeroshade as a code owner July 14, 2025 14:37
@zeroshade
Copy link
Copy Markdown
Member

Curious, somehow this change is causing a deadlock in the tests. I'll see if I can dig a bit and figure out the cause.

@arnoldwakim
Copy link
Copy Markdown
Contributor Author

arnoldwakim commented Jul 14, 2025

Curious, somehow this change is causing a deadlock in the tests. I'll see if I can dig a bit and figure out the cause.

I see what the issue was, and that's my bad. For some reason I did not push the code I intended in the first place.
On my local machine, I ran the test when draining the channel after this error check, which was fine.
The version I pushed was deferring before the error check causing the deadlocks since it was the equivalent of this:

var cc <-chan flight.StreamChunk

for chunk := range cc {
    ...
}

I have amended the commit and pushed the intended version. Sorry for the inconvenience.

[EDIT]:
Now the test pass, but not all the checks.

[2nd EDIT]:
All good. Sorry for the inconvenience.

@zeroshade
Copy link
Copy Markdown
Member

Nice, i'll take a look at seeing the best way to craft a unit test for this. Thanks for the fix!

Copy link
Copy Markdown
Member

@zeroshade zeroshade left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I plan on cutting a release, I think I'll get this in now and work out a test for it as a separate PR just to ensure this fix goes out with the release.

@zeroshade zeroshade merged commit f2773ad into apache:main Jul 14, 2025
26 of 27 checks passed
@arnoldwakim
Copy link
Copy Markdown
Contributor Author

Thanks for taking care of this 🫡

zeroshade pushed a commit that referenced this pull request Dec 29, 2025
…afe (#615)

### Rationale for this change

`StreamChunksFromReader` previously did not observe context
cancellation. As a result, if a client disconnected early, the reader
could continue producing data indefinitely, potentially blocking on
channel sends, leaking `RecordBatch` objects, leaking the reader, and
consuming unbounded memory and CPU (this observation triggered this PR).

This fix ensures that data streaming promptly stops when the client
disconnects.

### What changes are included in this PR?

- `StreamChunksFromReader` now accepts a `context.Context`.
- Tiny change was made to `DoGet`, to ensure it continues to work with
the context-aware `StreamChunksFromReader`.

### Are these changes tested?

- To be removed from description: the tests are bit tricky to write,
similar to that of #437. Maybe @zeroshade has suggestions?

### Are there any user-facing changes?

- `StreamChunksFromReader` now accepts a `context.Context`.

---------

Co-authored-by: awakim <arnold.wakim@gmail.com>
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.

flightsql.BaseServer does not exhaust channel in case of an error writing StreamChunks in DoGet

2 participants