Newer versions of rust-analyzer breaks when using multiple databases in SQLX

[Laursen79]

So, I have a very specific issue when using newer versions of rust-analyzer in my project.

The project is structured as follows:
It is a monorepo consisting of three crates: a client, a server and some common stuff. The client has a local SQLite database and the server has a PostgreSQL database. Both on the client and on the server we use SQLX to manage our interactions with their respective databases.

SQLX allows you to define a DATABASE_URL in your .env file, and therefore we have a .env file on the server with DATABASE_URL=<postgres_url> and on the client with DATABASE_URL=<sqlite_url>. This works fine when using cargo check, cargo test and cargo run, no issues there.

Using SQLX is nice because it allows compile-time checking of your SQL queries by evaluating them against the database.

Here's the kicker: When we hit save in NeoVim and rust-analyzer runs (on any version newer than 2024-09-16) on the client, the SQLite queries on the client are sent to the PostgreSQL database instead, leading to errors being displayed in the code when the queries inevitably fail. As stated earlier, there is no problem when running the code. There is only a problem when the rust-analyzer lsp checks the code.

rust-analyzer version: newer than 2024-09-16, installed through Mason

rustc version: rustc 1.82.0 (f6e511eec 2024-10-15)

editor or extension: NeoVim

[TaQuanMinhLong]

I'm having a similar issue as well
In my case, i have mutiple bin crates with cargo workspace setup,

services
    |-- service_1
    |-- service_2
    |-- service_n

each crate has its own .env file

Rust analyzer keeps yelling errors (like "relation does not exist...") while rustc doesn't
I did inspect and found that the rust analyzer was complaining because queries didn't go to the correct database as expected (for example, rust analyzer thought service_1 was querying to service_2's database and so on), but the truth is these .env files are all having correct connection setup

Edit:

• I use VsCode
• All bin crates in my case use postgres
• I fixed this by downgrading rust-analyzer to v0.3.2121

[Veykril]

I assume this might be due to the working directory we invoke cargo in? Not sure. Would be good to check which release regressed here

[rshigapov-bhft]

+1

Recently switched from per-workspace sqlx directory to per-crate configuration.

[zkrising]

Also having this issue, and it makes our monorepo effectively unusable. Haven't been able to fix this by reverting to an older version. cargo check et. al. work perfectly fine.

[ChayimFriedman2]

Do you have rust-analyzer.check.workspace: false? If yes, it is known it is not working since last couple versions, and the fix is in #18563.

[Laursen79]

@ChayimFriedman2, I have not done anything to configure rust-analyzer.

I can report that version 2024-12-09 is also not working.

[Veykril]

Would be helpful if someone could provide a minimal reproduction

[TaQuanMinhLong]

Things started to break from v0.3.2129

v0.3.2121 works fine for me

[Veykril]

The only remotely relevant change from that release would be #18184, but I don't see how that would have an effect there. Either way I'll need a reproduction here

[mhnap]

Do you have rust-analyzer.check.workspace: false? If yes, it is known it is not working since last couple versions, and the fix is in #18563.

Does someone know whether this is tracked and will be fixed? I'm using v0.3.2220 and still have such issue.

[Veykril]

Okay to note things, when we invoke cargo check, we currently either invoke cargo check --workspace or cargo check -p package (where package is the package belonging to the saved file). Notably, this command is spawned in the workspace root directory. So with that said, it would be good for the people here to clarify when they save running cargo themselves works, what exactly the invocation is (including what working directory is being used relative to the project).

[zkrising]

I'm using rust analyzer in the root of my workspace -- right where my workspace Cargo.toml is.

I have two crates, sqlite/ and postgres/, and two files:

# sqlite/.env
DATABASE_URL=sqlite://sqlite/template.db

# postgres/.env
DATABASE_URL=postgresql://postgres:password@localhost/my_app

If i have sqlx queries in -- say -- postgres/main.rs, they appear to be affected by the content of sqlite/.env AND postgres/.env.

For example. if I comment out the sqlite/.env file, rust-analyzer gives me the error message set DATABASE_URL to use query macros online, [..], indicating that it thinks postgres/main.rs somehow doesn't have a database url.

Furthermore, the errors I get inline are very confusing -- it will say columns don't exist, that do exist, or tables do exist, that don't. I've noticed that cargo clean, commenting out the .env files in the other project, and then restarting rust analyzer fixes things, but this is untenable and frustrating.

Also, it seems to be sort of random what errors I get. Sometimes it only tries to check the query against the sqlite db, sometimes only the postgres db. This happens sometimes, and regardless of what crate the query takes place in.

Note that cargo check in the terminal works perfectly, both in the workspace and with cargo check -p postgres.

Sorry that I can't be of more help, the code I'm working on is closed source.

[Veykril]

Note that cargo check in the terminal works perfectly, both in the workspace and with cargo check -p postgres.

Where, in which working directory? That is the important part, are you executing it manually in the workspace directory, or in the respective package one (that is within postgres /sqlite).

[TaQuanMinhLong]

Where, in which working directory? That is the important part, are you executing it manually in the workspace directory, or in the respective package one (that is within postgres /sqlite).

In my case, says we have 10 workspace folders, and 10 of them are located in ./services/<crate_name>, there are 2 or 3 being affected (I'm not sure if the number can go higher, as I only jumped around some workspace during that time), and the affected ones keep yelling error all the time, and this cannot be fixed either with cargo clean or restart the whole computer