[BUG] - Switching between signed in profiles prints error

[bigbeka]

Describe the bug
I am on version 0.75.0, and signed it to 2 Postgres profiles. When switching between profiles, the UI prints Error signing you in: unauthorized, although I am signed in to both profiles. The issue seems to be with missing or wrong default Database and Schema options chosen when a given profile is selected.

To Reproduce

1. Login to two profiles
2. Switch from one profile to another
3. Previous profile's database is chose, but current profile doesn't have that database, hence error occurs.
4. If the page with the new profile is manually reloaded, then I can choose the correct Database and Schema from dropdown and the correct tables are displayed.

Expected behavior
When I switch between profiles, the correct (default/previous) Database and Schema for that Profile should be chosen.

This is a docker compose logs:

whodb-1  | 2025/11/16 12:35:35 [d3644c08bf58/QQA1nn3B1P-000586] "POST http://whodb.lan/api/query HTTP/1.1" from xx.xx.xx.xx - 200 107B in 7.025121ms
whodb-1  | 
whodb-1  | 2025/11/16 12:35:38 /app/src/plugins/postgres/db.go:62
whodb-1  | [error] failed to initialize database, got error failed to connect to `user=user database=prod`: xx.xx.xx.123:5432 (xx.xx.xx.123): server error: FATAL: database "prod" does not exist (SQLSTATE 3D000)
whodb-1  | 2025/11/16 12:35:38 [d3644c08bf58/QQA1nn3B1P-000587] "POST http://whodb.lan/api/query HTTP/1.1" from xx.xx.xx.xx - 200 68B in 6.818123ms
whodb-1  | time="2025-11-16T12:35:38Z" level=error msg="Failed to connect to PostgreSQL database" database=prod error="failed to connect to `user=user database=prod`: xx.0.0.123:5432 (xx.0.0.123): server error: FATAL: database \"prod\" does not exist (SQLSTATE 3D000)" hostname=xx.0.0.123 port=5432 username=user
whodb-1  | time="2025-11-16T12:35:38Z" level=error msg="Database connection failed during login - credentials unauthorized" database=prod hostname=xx.0.0.123 type=Postgres username=user
whodb-1  | 2025/11/16 12:35:38 [d3644c08bf58/QQA1nn3B1P-000588] "POST http://whodb.lan/api/query HTTP/1.1" from xx.xx.xx.xx - 200 27B in 21.222514ms

[modelorona]

Recording.2025-11-28.214055-new.mp4

hi @bigbeka was checking this out, I believe it's an easy fix and was testing it locally.

In the video above (start at 8 seconds, something weird happened when I downscaled it and the first 8 seconds are useless), switching between the profiles shows me no error on the UI or in the backend logs.

Granted it can be improved by remembering the previous tables/schema selected, but I believe it fixes the original issue you had. Let me know when you get a chance :)

[modelorona]

it's merged into main, and we will aim to release today/tomorrow :)

[bigbeka]

Thank you will check and report back :)

[bigbeka]

I pulled down the :latest version and tested it, and the bug still exists. When switching between two Postgres databases (prod and stage in my case), WhoDB does not automatically reload the schema and database dropdown and errors out when it tires to load the stage DB for prod instance, and vice versa.

STDOUT error when tripping to switch from prod to stage Postgres:

whodb-1  | [error] failed to initialize database, got error failed to connect to user=username database=prod: xx.x.x.x:5432 (xx.xx.xx.xx): server error: FATAL: database "prod" does not exist (SQLSTATE 3D000)

My Postgres setup (so you could try to recreate the error on your side:
Postgres 1: 192.168.1.10 > prod > public
Postgres 2: 192.168.1.11 > stage > public

Both Postgres instances have postgres database as well in addition to prod and stage.
So the error/bug occurs when switching between 192.168.1.10 and 192.168.1.11, the Database dropdown does not "Re-pull" the database of the currently selected Postgres instance but instead looks for the previously chosen instance's database, which obviously doesn't exist.

This applies to version 0.80.0 that you just pushed. I am not sure if it finished building though.

[modelorona]

I've been trying to sort this out locally but haven't been able to find the root cause - thought it might be something to do with how Apollo refreshes the data on profile switch but no luck. Will need to get @hkdeman to take a look, he's the frontend guru