launchbadge
Unable to Connect to StarRocks in Version 0.8.5 (Works Fine in 0.8.3)
I have found these related issues/pull requests
not found
Description
Could you investigate whether there were any changes in the MySQL driver or connection handling logic between versions 0.8.3 and 0.8.5 that might cause this issue? Alternatively, if this is a known issue, guidance on how to resolve it would be appreciated.
Thank you for your time and support!
Reproduction steps
Steps to Reproduce: 1.Use the following connection string or configuration to connect to StarRocks:
let options = MySqlConnectOptions::new() .host(conf.get("host").unwrap()) .port(conf.get("port").unwrap().parse()?) .username(conf.get("username").unwrap()) .password(conf.get("password").unwrap()) .timezone(String::from("+08:00")) .no_engine_substitution(false) .pipes_as_concat(false);
2.Run the code with sqlx version 0.8.5. 3.Observe that the connection fails. 4.Downgrade to sqlx version 0.8.3 and run the same code. 5.Observe that the connection succeeds.
SQLx version
0.8.5
Enabled SQLx features
"chrono", "mysql", "runtime-tokio", "bigdecimal"
Database server and version
StarRocks3.3.9
Operating system
CentOS7.9
Rust version
rustc 1.85.1 (4eb161250 2025-03-15)
It would be helpful if you provided the actual error message.
The only significant change to the internals of the MySQL driver since 0.8.3 would be https://github.com/launchbadge/sqlx/pull/3812
@abonander
Error: got unexpected connection status after attempting to begin transaction
Stack backtrace:
0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/anyhow-1.0.98/src/backtrace.rs:27:14
1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:2014:27
2: srctl::main::{{closure}}
at ./srctl/src/bin/main.rs:68:18
3: <core::pin::Pin<P> as core::future::future::Future>::poll
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:124:9
4: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/park.rs:284:60
5: tokio::task::coop::with_budget
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/task/coop/mod.rs:167:5
6: tokio::task::coop::budget
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/task/coop/mod.rs:133:5
7: tokio::runtime::park::CachedParkThread::block_on
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/park.rs:284:31
8: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/context/blocking.rs:66:9
9: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}}
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/scheduler/multi_thread/mod.rs:87:13
10: tokio::runtime::context::runtime::enter_runtime
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/context/runtime.rs:65:16
11: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/scheduler/multi_thread/mod.rs:86:9
12: tokio::runtime::runtime::Runtime::block_on_inner
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/runtime.rs:370:45
13: tokio::runtime::runtime::Runtime::block_on
at /home/PC/.cargo/registry/src/rsproxy.cn-e3de039b2554c837/tokio-1.44.2/src/runtime/runtime.rs:340:13
14: srctl::main
at ./srctl/src/bin/main.rs:88:5
15: core::ops::function::FnOnce::call_once
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
16: std::sys::backtrace::__rust_begin_short_backtrace
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:152:18
17: std::rt::lang_start::{{closure}}
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:199:18
18: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/core/src/ops/function.rs:284:13
19: std::panicking::try::do_call
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:587:40
20: std::panicking::try
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:550:19
21: std::panic::catch_unwind
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panic.rs:358:14
22: std::rt::lang_start_internal::{{closure}}
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/rt.rs:168:24
23: std::panicking::try::do_call
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:587:40
24: std::panicking::try
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:550:19
25: std::panic::catch_unwind
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panic.rs:358:14
26: std::rt::lang_start_internal
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/rt.rs:164:5
27: std::rt::lang_start
at /home/PC/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:198:5
28: main
29: __libc_start_call_main
at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
30: __libc_start_main_impl
at ./csu/../csu/libc-start.c:360:3
31: _start
Process finished with exit code 1
That's likely a result of #3765, specifically this bit of code: https://github.com/launchbadge/sqlx/blob/bab1b022bd56a64f9a08b46b36b97c5cff19d77e/sqlx-mysql/src/transaction.rs#L33-L35
It likely means that StarRocks responded to a BEGIN statement with an OK packet without the SERVER_STATUS_IN_TRANS flag set.
SQLx is behaving correctly here. This is a protocol compatibility bug in StarRocks.
@abonander As Starrocks is an OLAP database, not like MySQL which is an OLTP, it does not support multi-row SQL transactions that may change some connection characteristics. Previously in version 0.8.3, I used the method .no_engine_substitution(false) to connect to Starrocks. However, even in version 0.8.5, I still used .no_engine_substitution(false). The code is as follows:
let options = MySqlConnectOptions::new()
.host(conf.get("host").unwrap())
.port(conf.get("port").unwrap().parse()?)
.username(conf.get("username").unwrap())
.password(conf.get("password").unwrap())
.timezone(String::from("+08:00"))
.no_engine_substitution(false)
.pipes_as_concat(false);
"Is it possible that modifying the value of .no_engine_substitution can solve the issue?"
No, but there's also nowhere that we begin a transaction in the code path of opening a connection.
The only time the MySQL driver implicitly begins a transaction is when running migrations: https://github.com/launchbadge/sqlx/blob/bab1b022bd56a64f9a08b46b36b97c5cff19d77e/sqlx-mysql/src/migrate.rs#L180