Problem
close_statement removes the statement from self.statements before the bytes that tell the server to close it have actually been acknowledged as sent. If the flush that carries those bytes fails, the connection's own internal bookkeeping believes the statement is gone while the MySQL server still holds it open.
Why it matters
This is a state-tracking bug inside the crate itself: a failed flush after close_statement leaves the host's connection object and the real server disagreeing about which prepared statements still exist, with no way for the host to detect or recover from the mismatch through the crate's own API.
What would fix it
Removing the statement from self.statements only after the closing bytes are acknowledged as sent (mirroring how other acknowledgement-gated state transitions in the crate work), so a failed flush leaves the bookkeeping consistent with what the server actually has.
Problem
close_statementremoves the statement fromself.statementsbefore the bytes that tell the server to close it have actually been acknowledged as sent. If the flush that carries those bytes fails, the connection's own internal bookkeeping believes the statement is gone while the MySQL server still holds it open.Why it matters
This is a state-tracking bug inside the crate itself: a failed flush after
close_statementleaves the host's connection object and the real server disagreeing about which prepared statements still exist, with no way for the host to detect or recover from the mismatch through the crate's own API.What would fix it
Removing the statement from
self.statementsonly after the closing bytes are acknowledged as sent (mirroring how other acknowledgement-gated state transitions in the crate work), so a failed flush leaves the bookkeeping consistent with what the server actually has.