5 months ago
my template has an application server that depends on a database backend.
the environment variables are setup to follow the startup order documentation here https://docs.railway.com/deployments/deployment-actions#deployment-dependencies---startup-ordering but when deploying the application from a template, the application server always starts before the database and errors out.
my env var:
DATABASE_URL=${{Timescale.DATABASE_URL}}Pinned Solution
5 months ago
My theory is that the health check on your main service is clashing with the start up order. The start up order makes sure that the database is deployed before the main service is. However, since your main service has a health check, it means your service will actually run and do what it has to do before the status changes to deployed, essentially trying to access the database even if the database isn't deployed yet. Hence why I suggested to move the migrations to a predeploy step, which will potentially actually wait for your database to be deployed first before running the migration.
8 Replies
Status changed to Awaiting Conductor Response brody • 5 months ago
Status changed to Awaiting User Response Railway • 5 months ago
Status changed to Awaiting Conductor Response Railway • 5 months ago
tracearr
sure, try <https://railway.com/deploy/derwSY>
5 months ago
Hmmm, I am not sure if it's just the health check that is clashing with the start up dependency order, can you try putting the migration into a predeploy step and see if the predeploy step is actually executed after the database has been deployed?
Status changed to Awaiting User Response Railway • 5 months ago
Status changed to Awaiting Conductor Response Railway • 5 months ago
5 months ago
i dont have any migrations, or anything that i could possibly put into predeploy. i am a little confused here
tracearr
i dont have any migrations, or anything that i could possibly put into predeploy. i am a little confused here
5 months ago
I suppose the seeding of your database (your application is trying to perform some kind of migration at the start)?
Attachments
Status changed to Awaiting User Response Railway • 5 months ago
5 months ago
yes, but those migrations only happen if the db connection is successfull otherwise it keeps retrying. its not a show stopper for us but i just thought that was the whole point of the startup ordering in Railway - to prevent that.
the database has a health check, but obviously its not http and thats all Railway supports 😕
is it too much to ask for a startup order delay setting? X seconds after db starts ?
Status changed to Awaiting Conductor Response Railway • 5 months ago
tracearr
yes, but those migrations only happen if the db connection is successfull otherwise it keeps retrying. its not a show stopper for us but i just thought that was the whole point of the startup ordering in Railway - to prevent that. the database has a health check, but obviously its not http and thats all Railway supports 😕 is it too much to ask for a startup order delay setting? X seconds after db starts ?
5 months ago
My theory is that the health check on your main service is clashing with the start up order. The start up order makes sure that the database is deployed before the main service is. However, since your main service has a health check, it means your service will actually run and do what it has to do before the status changes to deployed, essentially trying to access the database even if the database isn't deployed yet. Hence why I suggested to move the migrations to a predeploy step, which will potentially actually wait for your database to be deployed first before running the migration.
Status changed to Awaiting User Response Railway • 5 months ago
Status changed to Solved tracearr • 5 months ago