`server_version` not sent in parameter_status at end of authentication about supavisor HOT 4 CLOSED

what happens if Supavisor can't establish a connection to the db? i.e. the password both the user used and that's stored in tenants turns out to be incorrect?

Hmm, yeah, that behavior creates an infinite loop in the db_handler until the manager kills the connection tree 🤦‍♂️
I'll fix this and make it more robust in a separate PR

from supavisor.

Thanks for reporting! For our internal needs, we want to allow connections even if the database is not responding. However, it, of course, sucks if the client fails on a cold start, especially when it's Postgrex.

As a potential solution, I suggest adding a wait timeout. During this period, if we receive parameter_status from the database, we can forward it to the client, or alternatively, send a "stub" packet with a server version of 0.0.
I prepared a small fix #101, WDYT?

cc @chasers

from supavisor.

@abc3 Just took a look at your PR -- looks like a great solution! This feels right to me. I just ran some tests against your branch and it worked great.

Tangential question: what happens if Supavisor can't establish a connection to the db? i.e. the password both the user used and that's stored in tenants turns out to be incorrect?

from supavisor.

Could you take a look at #114 fix? It will stop the DbHandler retries, and the next client connection attempt will relaunch the pools with the correct credentials

from supavisor.