Hey, are you still facing this issue? I can see that your latest deploy is working

yeah, but i cant use the database_private_url, its only show me a error.

Are you getting this error during build or during runtime?

i dont run migrations during building, only in start command

i dont run migrations during building, only in start command

I'm sorry but that doesn't quite answer my question.

see it

Are you getting this error during build or during runtime?

after the building, is in start, runtime

Is the Postgres database in the same project? it needs to be.

Is the service using the V2 runtime? It should be, check the service settings.

Is the Postgres database in the same project? it needs to be.

Is the service using the V2 runtime? It should be, check the service settings.

yeah, both in the same project, but in separate services, my service in nodejs is running with v2, but the postgres not.

There is something misconfigured here, so I will defer to the team here as they are able to look at the project and I am not.

Apologies for the delay. We've traced the issue and found that:

Your initial error was

Context: Timed out trying to acquire a postgres advisory lock (SELECT pg_advisory_lock(72707369)). Elapsed: 10000ms. See https://pris.ly/d/migrate-advisory-locking for details.

We think this happened because you have two replicas, and run migrations as part of starting the deploy. If one replica grabbed the lock, the other replica would get freezed out by Prisma's design. Prisma does this to prevent the same migration from being ran in parallel as that would very likely result in some manner of data corruption.

This can happen in cases where you're running a large migration that isn't fast enough to complete, so if you were running a migration as part of that deploy, it's likely that having two replicas attempting to run it caused issues.

Thereafter, you restarted your database through the dashboard, which caused subsequent deploys to fail to connect to the database as it was still starting up. Looking through your database's logs, you can see that it's attempting to replay the WAL and ensuring that your database is still in a good state after the restart. This might take awhile if you have a fair amount of pending writes. The other network failures occurred in this time period where your database was still restarting and attempting to fix itself.

Sorry you ran into this. If you want to prevent it in the future, I'd recommend that when running large Prisma migrations that can take awhile, scale your service down to 1 replica to ensure you only run the migration exactly-once.

Hello, we understand now, thank you for the explanations!! You can close this topic, thanks