I’m trying to use the hosted supabase service with my phoenix app, and setting up a staging environment for testing.
But, our CI fails on 70% of deploys, if no-one has used the app recently. If we make a web request: the app machine starts again and deploys work.
I know this is a bit edge-case, but is this expected? As far as I can tell, as we’re paying the supabase fees (which are not billed per minute), I’d expect this database to be online at all times?
Is our only option to disable auto-turn-off on the fly machines as well? (And incur the extra billing there too)?
EDIT: Clarification, I forgot to say, the deploy fails because the post-release command can’t run migrations, because the database can not be contacted. This is not a config issue, as half our deploys work. If a deploy fails, we load the app in the browser and deploy again and it succeeds.
This is strange, I use supabase postgres and have no issues when it sleeps. It should auto wake when a request comes in, so no idea why it’s failing for you.
It wakes when we make web requests. But if the fly machine is sleeping, we can’t deploy the app because the fly post-deploy migration can’t contact the database.
Is your migration coupled with your app being up?
Usually your migration script should be decoupled from everything and you’d just run it in your CI/CD before building/deploying your app.
You can also inject the migration in code in your app’s bootstrap phase and it would no-op if there’s nothing to migrate.
Maybe a quick workaround is to curl your app to wake it up in a step before the deployment?
No, the migration is not coupled to the app. It just needs a connection to the DB.
The issue is that the DB is down when the app is sleeping, when I believe we’re paying for it to be online all the time. That is, if we were paying Supabase directly, the DB would always be connectable. Now that it’s on/via fly, and we’re paying the same amount but the DB machine appears to be sleeping alongside the app itself.
We could hack it with curl, but I’m trying to get clarification on the Fly setup and if this should be happening or not.
I’m seeing a variation of this same issue. If my VM is asleep, and I visit my phoenix app, then I’ll see an “internal error” boilerplate page - I haven’t yet investigated if this is generated by fly.io or phoenix, but the logs yield the following - notably, subsequent requests work fine once the machine is green.
[error] ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2021ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
2024-09-23T23:13:14Z app[4d896d2f9ee9d8] ord [info] 1. Ensuring your database is available and that you can connect to it
2024-09-23T23:13:14Z app[4d896d2f9ee9d8] ord [info] 2. Tracking down slow queries and making sure they are running fast enough
2024-09-23T23:13:14Z app[4d896d2f9ee9d8] ord [info] 3. Increasing the pool_size (although this increases resource consumption)
2024-09-23T23:13:14Z app[4d896d2f9ee9d8] ord [info] 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
2024-09-23T23:13:14Z app[4d896d2f9ee9d8] ord [info]See DBConnection.start_link/2 for more information```