Port forwarding on kubernetes still broken - unable to prisma migrate deploy #30074
|
I just ran into #17452 again when I tried to deploy a migration with 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. |
Replies: 7 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 |
|
@paramjeetn thank you for your reply. The suggested connection parameter |
|
Ah, I found the |
|
I think the important distinction here is that In Prisma 6, Also, So for this particular
Reducing the pool size won't solve that underlying race. The most reliable solution is to remove the port-forward from the migration path and run If the goal is specifically to make local port-forwarding reliable, I'd treat that as a Kubernetes port-forward/reconnection problem rather than a Prisma connection-pool configuration problem. A retry around the entire |
|
@kingofdead6 thank you for the hints. It is a port-forward problem, however Prisma triggers the issue and then stumbles upon its own feet instead of working around it as other solutions are able to do. In my opinion, it's still a bug in Prisma that it should fix in its own interest. |
I think the important distinction here is that
connection_limitis not really the knob to use for this problem in Prisma 7.In Prisma 6,
connection_limit,connect_timeout, andpool_timeoutwere URL parameters for Prisma's built-in connection pool. In Prisma 7, the connection-pool configuration moved to the database driver/adapter (for example,maxandconnectionTimeoutMillisfor@prisma/adapter-pg).Also,
prisma migrate deployis not using the Prisma Client connection pool in the same way your application does. Its job is simply to apply the migration files to the configured datasource, and Prisma's v7 docs don't expose aconnection_limitoption formigrate deploy.So for this particular
P…