Skip to content

Conversation

@jbielick
Copy link

@jbielick jbielick commented Dec 9, 2025

Purpose

#565

The needs_drain() condition prior to this commit checks the connection state is some kind of idle or otherwise "in sync". However, even when the connection state is Idle, there can be expected messages in the protocol queue. If a client disconnects abruptly at just the right time, needs_drain() would not return true, but the protocol queue is not empty and expected messages from the server are not drained.

In this scenario, the connection is checked back in in a tainted state and subsequent usage can produce unexpected results (ProtocolOutOfSync or off-by-1 results mixups).

Fix

This updates needs_drain() to also account for
prepared_statements.has_more_messages() in addition to the "in sync" check, thus triggering a drain when there are more messages expected from the server (and tracked in the protocol queue).

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

The needs_drain() condition prior to this commit checks the connection
state is some kind of idle or otherwise "in sync". However, even when
the connection state is Idle, there can be expected messages in the
protocol queue. If a client disconnects abruptly at just the right time,
needs_drain() would not return true, but the protocol queue is not empty
and expected messages from the server are not drained.

In this scenario, the connection is checked back in in a tainted state
and subsequent usage can produce unexpected results (ProtocolOutOfSync
or off-by-1 results mixups).

This updates needs_drain() to also account for
prepared_statements.has_more_messages() in addition to the "in sync"
check, thus triggering a drain when there are more messages expected
from the server (and tracked in the protocol queue).
@jbielick jbielick force-pushed the 565-pending-prepared-statements-drain-while-idle branch from 9567327 to 2369f72 Compare December 9, 2025 22:26
Comment on lines +672 to +673
ProtocolMessage::from(Query::new("SELECT 1")),
ProtocolMessage::from(Query::new("SELECT 1")),
Copy link
Author

Choose a reason for hiding this comment

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

Holding off on this PR because stuffing the ClientRequest like this doesn't seem to be a realistic reproduction. Addressing some of the out-of-sync side effects in #668 instead.

@jbielick jbielick closed this Dec 10, 2025
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.

2 participants