sqlx: Mysql failure while dropping a future in the middle of reading or writing to the stream.

I think the best course of action would be to drop the connection from the pool, if a query/query result is dropped before it is done. This is much easier than somehow trying to cancel the query and recover the connection, though it is much less performant. I can try to create a PR to implement this, if the maintainers would be willing to merge something with that approach.

We’ve found that it’s possible to see a panic after https://github.com/launchbadge/sqlx/blob/6a70780f4552c9f5afbf867cc639ea0ea375ae29/sqlx-core/src/mysql/connection/stream.rs#L147 returns Bytes of size 0, so [0] is out of bounds and causes a panic.

The only way I can see that happening is if the packet_size comes back 0, which we’d see if this returns a 0:

let packet_size = header.get_uint_le(3) as usize;

because the read buffer will always be set to the size it’s asked to read: https://github.com/launchbadge/sqlx/blob/6a70780f4552c9f5afbf867cc639ea0ea375ae29/sqlx-core/src/io/buf_stream.rs#L115

Should I PR on throwing a new error if the packet size is 0? Or is a 0 packet size okay and we should simply not do this if it is 0 if payload[0] == 0xff { , to avoid the panic? Or does a 0 packet size indicate that the header wasn’t read correctly/stream queried properly?