You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Flight SQL] ClosePreparedStatement uses original handle instead of updated handle from server #1117
Describe the bug, including details regarding any error messages, version, and platform.
When using the FlightSqlClient.PreparedStatement flow, the client uses the original prepared statement handle when invoking ClosePreparedStatement, rather than the updated handle returned by the server when binding parameters.
Observed behavior
After preparing a statement, the server may return an updated handle in binding parameters call.
The client correctly uses the updated handle for Execute.
However, when calling ClosePreparedStatement, the client still uses the original handle stored in the final field preparedStatementResult.
Expected behavior
Based on my understanding of the protocol, once the server returns an updated handle, the client should consistently use that handle for all subsequent operations.
By specification on FlightSql.proto file:
// Because the handle could potentially be updated, any previous handles for this prepared
// statement should be considered invalid, and all subsequent requests for this prepared
// statement must use this new handle.
Impact
In a custom server implementation I'm developing, this causes inconsistencies because:
the server expects the updated handle for all follow-up calls, including new put parameter calls and ClosePreparedStatement
ClosePreparedStatement fails or behaves unexpectedly when the original handle is used
Question / clarification
Is this the intended behavior according to the Flight SQL protocol, or is this a bug in the client implementation?
If this is expected, It's quite simple to adjust my server logic accordingly, but wanted to confirm that is not a bug on client implementation.
This is a bug indeed. If you look at line 1347 of FlightSqlClient, the new handle is used but never stored for further operations. I will put out a PR to fix this. Thanks for the bug report!
Activity
ennuite commentedon Apr 18, 2026
This is a bug indeed. If you look at line 1347 of
FlightSqlClient, the new handle is used but never stored for further operations. I will put out a PR to fix this. Thanks for the bug report!ennuite commentedon Apr 18, 2026
Take
apacheGH-1117: Use updated handle in prepared stmt (apache#1120)