Panic in sqlx: assertion failed: self.remaining() >= dst.len()

[stepantubanov]

Bug Description

sqlx panics somewhere in sqlx_core::mysql::protocol::statement::prepare_ok::PrepareOk::decode_with:
https://github.com/launchbadge/sqlx/blob/v0.6.3/sqlx-core/src/mysql/protocol/statement/prepare_ok.rs#L19-L35

Message: assertion failed: self.remaining() >= dst.len()

Backtrace:

sqlx_core::mysql::protocol::statement::prepare_ok::PrepareOk::decode_with

sqlx_core::mysql::connection::executor::<T>::run::{{closure}}::{{closure}}::{{closure}}

futures_util::future::future::fuse::Fuse<T>::poll

sqlx_core::ext::async_stream::TryAsyncStream<T>::poll_next

futures_util::future::future::fuse::Fuse<T>::poll

sqlx_core::ext::async_stream::TryAsyncStream<T>::poll_next

sqlx_core::mysql::connection::executor::<T>::fetch_optional::{{closure}}

Minimal Reproduction

I do not have a reproducible example yet. But wanted to raise this issue to discuss:

• Error handling when parsing SQL messages from the server. Is there a way we can get just an Err when something like this happens (parsing fails) instead of a panic? Is it safe to continue using such connection or it has to be dropped from the pool?

• Cancellation safety of sqlx futures. Is it safe to assume that any fetch can be safely cancelled (future dropped)? We have some code that probably drops some of the futures while doing fetch with an ANALYZE query. Just wondering if it could be related to the issue.

Info

• SQLx version: 0.6.3
• SQLx features enabled: ["runtime-tokio-rustls", "mysql", "chrono", "uuid"]
• Database server and version: MariaDB 10.6.11
• Operating system: linux
• rustc --version: 1.69 stable

[JuxhinDB]

I've just hit this bug as well, in my case it's occurring on an upsert table, where an initial insert works fine but a subsequent update fails with the same issue.

thread 'tokio-runtime-worker' panicked at 'assertion failed: self.remaining() >= dst.len()',

Will notify here if I came across a solution for this or further details.

[JuxhinDB]

@stepantubanov not sure this helps, my issue was decoding a JSONB column into a Vec<Json<T>>:

SELECT
    a.foo AS "foo: Vec<Json<Foo>>"
FROM
    ...

The solution was to wrap the outer type in Json instead, so Json<Vec<T>>.

[stepantubanov]

@JuxhinDB
Oh, interesting. Did you get the panic in PrepareOk as well? In our case we're not using Json or JSONB.

[JuxhinDB]

@stepantubanov correct however this is from previous sqlx version, so I'm not sure if this applies still with the latest PR.