Losing connection to the database results in `query!` macros returning errors permanently in rust-analyzer

[swlynch99]

I have found these related issues/pull requests

Not related to any other issue that I could find. The closest seems to be #3738 but that is definitely a different issue.

Description

sqlx::query! and friends open a single database connection and use that to talk to the database. If that connection goes away then any later macros will error. This is not a problem for regular compilation, but rust-analyzer will keep the macro library loaded indefinitely. Once the connection is lost then the only way to get rid of the errors is to completely restart rust-analyzer.

I think the correct thing to do in this case is to try and reconnect to the database after receiving a connection/protocol error so that the next query, at least, is able to continue working appropriately.

Reproduction steps

1. Set up a postgres database.
2. Configure sqlx to point to this database.
3. Write a query that uses the database. For example,

   fn do_query(conn: &mut sqlx::PgConnection) {
      let _ = sqlx::query!("SELECT * FROM information_schema.tables").fetch_all(conn).await;
   }

4. Restart the database (or otherwise break the connection)
5. Modify the query. You will get the following error

   error communicating with database: expected to read 5 bytes, got 0 bytes at EOF
   

   At this point any attempt to run a sqlx query macro will result in this error, regardless of whether the database is reachable or not.

SQLx version

v0.8.6

Enabled SQLx features

runtime-tokio-native-tls,postgres,uuid,chrono,json,ipnetwork but I suspect this will happen with any database backend

Database server and version

Postgres 15

Operating system

Linux (within WSL2)

Rust version

rustc 1.90.0-nightly (a00149764 2025-07-14)

[zjqFocus]

I believe this does not affect the implementation of user business functionalities. Enforcing offline mode builds may mitigate the impact of this issue.

[zjqFocus]

Alternatively, we could add logic to automatically detect network connectivity in the future, but this approach may introduce significant additional workload.

[swlynch99]

I feel that it's worth pointing out that the biggest problem for me is that the error is permanent. If error occurs temporarily but then resolves itself then that would actually be perfectly fine for me here, even if that temporary error was technically spurious.

Would something like this work: If a query! macro encounters a protocol or connection error then it removes the cached database connection before passing the error on up.

It will still result in an error, but future macro evaluations will be able to re-establish a connection. It doesn't require proactively checking the connection for liveness so it shouldn't have much in the way of performance issues unless the database is actually unreachable.

[abonander]

I'd gladly accept a PR to drop connections on error. We shouldn't retry in the macro since it could block the compiler invocation.

However, ultimately we're completely at the whim of Rust Analyzer here and when it decides to re-run the macros. While we can do some things to improve the reliability, I don't think there's any getting around the user just having to restart RA once in a while.

[tgrushka]

Why was this issue closed? This is a major, major annoyance, and very predictable -- occurs 95% or more of the time for me on repeated cargo checks after the first query in VS Code when running postgres in Docker.

Seems to be a timeout error, as if sqlx puts macro call timeout at 1 millisecond or something. No way to tell. sqlx does not even respect a "?connect_timeout=10" parameter on the DATABASE_URL, and it seems there is no other way to set a connection timeout, not even an env var.

The only workaround for me is running: Developer: Reload Window in VS Code, which starts "fresh" again, but then modify one line in a query and save, and BOOM:

error communicating with database: expected to read 5 bytes, got 0 bytes at EOF

This is just downright intolerable.

Very, very easy to reproduce. Just spin up a docker compose with your dev database in a postgresql service and try to use sqlx build-time macros. Nothing special here.

I guess I will open a new issue. People will just keep re-opening this problem again and again until fixed. Why can't we just have a timeout on the compile-time queries? That would almost certainly fix it due to the inherent additional latency introduced by Docker.