Replies: 3 comments
|
Retry the whole Why Why a reconnecting schema engine would be worse than the current failure. let migration_id = connector
.migration_persistence()
.record_migration_started(unapplied_migration.migration_name(), &script)
.await?;
match connector.apply_script(unapplied_migration.migration_name(), &script).await {
Ok(()) => { /* record_successful_step + record_migration_finished */ }
Err(err) => { /* record_failed_step */ }
}The On top of that, the engine serialises concurrent migrators with a session-level lock — Your failure is at initial connect ( What I'd actually do: run the migration in-cluster. This removes the tunnel entirely and is the same image you already ship: apiVersion: batch/v1
kind: Job
metadata:
name: prisma-migrate
spec:
backoffLimit: 2
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: your-app:TAG # same tag as the deploy that follows
command: ["npx", "prisma", "migrate", "deploy"]
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-credentials
key: url
If you're stuck driving it from your laptop, put the retry around the whole command and check the table before each attempt, so a P3009 stops you rather than compounding: for i in 1 2 3 4 5; do
npx prisma migrate deploy && break
echo "attempt $i failed; verifying migration state"
psql "$DATABASE_URL" -c \
"select migration_name, started_at, finished_at, rolled_back_at
from _prisma_migrations where finished_at is null;"
sleep 5
doneAny row returned there means the next Note also that WebSocket port-forward ( Source references are against |
|
Thank you for the lengthy replai. Rerunning the command didn't change anything, it still breaks. I still think it's a prisma issue and it should be fixed by prisma as one can see in the linked discussion that has been closed. |
|
When running Workarounds that resolve this:
DATABASE_URL="postgresql://user:password@localhost:5432/mydb?connection_limit=1&connect_timeout=30&pool_timeout=30"This forces Prisma schema engine to serialize database operations on a single stable socket without spawning concurrent pools over the tunneled port.
apiVersion: batch/v1
kind: Job
metadata:
name: prisma-migrate-job
spec:
template:
spec:
containers:
- name: migrate
image: your-app-image
command: ["npx", "prisma", "migrate", "deploy"]
restartPolicy: Never |
Uh oh!
There was an error while loading. Please reload this page.
I just ran into #17452 again when I tried to deploy a migration with
prisma migrate deploy. The postgres port was forwarded to my computer viakubectl port-forwardinside awhileloop to ensure that whenever the connection drops (this is an unsolved issue with kubectl kubernetes/kubectl#1746), it is reestablished. With the following prisma versions, I wasn't able to deploy migrations successfully:Here are the prisma logs:
On the side of kubectl, I get the following logs when I run the prisma command:
Due to the kubectl issue with postgres being unsolved, I think it would be best for prisma to improve its reconnect abilities. Tools like dbeaver or psql run into the same disconnect issues, however it seems like they just continue and try again so they work without the user noticing.
All reactions