Repository navigation
Test postgresql connection/table on startup #52
Description
It would be really nice if the daemon tested that it can connect to the postgresql db and has the right database schema set up on startup so that you don't just get the errors later at runtime.
Metadata
Metadata
Assignees
Labels
No labels
Activity
TheBlueMatt commentedon Aug 11, 2025
Usually this kind of application will also create and tables it needs in the database, if they're missing, so we should do that too.
G8XSU commentedon Aug 11, 2025
It is intentional to not check db connection on startup to avoid cascading failures in distributed service deployments.
In case, this service is unable to communicate with DB over network, you don't want this service to go down or start failing deployments for vss.
Let's assume one more service was dependent on vss, should it fail to startup/deploy because it can't communicate with vss? I don't think so.
This kind of approach makes sense in local only setups but for production usually infrastructure setup like spinning up a db cluster or table setup is separated out from service itself, and has stricter guardrails.
TheBlueMatt commentedon Aug 12, 2025
Huh? I've never seen a service that requires DB access happily start running if it can't connect to the DB. I agree that shutting down due to DB connection failures can start cascading failures, but starting up is pretty different - if you were previously down the failure already happened, failing to start doesn't worsen it. Not failing to start, on the other hand, can lead to worse outcomes - if you have a distributed deployment with a bunch of VSS instances and you misconfigure the DB connection string you'll end up with half of them broken and the other half working and trying to service requests from all of them, especially since we have no way to figure out if an instance is even working - #29
tankyleo commentedon Jun 3, 2026
Fixed in #55