Attempt to reconnect to the provided database at startup.

[ghost]

Describe the bug When entrypoint.sh starts with answer init, and the database is not ready for connections yet, the whole process fails and does not attempt to reconnect to the database.

To Reproduce I found this out by deploying a sidecar for GCP cloud-sql-proxy. The startup of answer happens so quickly that the cloud-sql-proxy is not completely ready to accept connections yet and then startup fails because the database is not ready. I was able to get passed this by bypassing entrypoint.sh and adding a 5 second sleep before answer init runs.

Expected behavior Ideally, the process would keep trying to connect to the provided database in config.yaml if its there from a previous configuration.

Platform (please complete the following information):

• OS: Kubernetes (GKE)
• Answer Version 1.0.7
• Database: Postgres

[LinkinStars]

@cl-christschantz I'm not really sure, but would it be possible to try starting the database proxy first and using readiness to ensure that sidecar has finished starting first before starting Answer?

[ghost]

@LinkinStars Thanks for the response. In Kubernetes, containers are spun up in parallel so there is not really a way to control timing or order of when they start. Unlike docker where you can use depends_on.