fix deploy issue

Author: Mohammad-R-Rashid

k8s/api.yaml

@@ -77,6 +77,11 @@ spec:
   # This ensures the load balancer has fully picked up the new pod before traffic
   # shifts — the key ingredient of zero-downtime blue-green deploys.
   minReadySeconds: 10
+  # api-ingest is hard-colocated with the current Postgres primary. During
+  # deploys the replacement pod can wait for that single node's allocatable CPU
+  # while the old pod finishes termination and CronJobs settle, so keep the
+  # progress deadline longer than the default 10m rollout window.
+  progressDeadlineSeconds: 1800
   strategy:
     type: RollingUpdate
     rollingUpdate:

package.json

@@ -1,6 +1,6 @@
 {
   "name": "rejourney-monorepo",
-  "version": "3.1.188",
+  "version": "3.1.189",
   "private": true,
   "description": "Rejourney Monorepo - Session Recording Platform",
   "workspaces": [

scripts/k8s/deploy-release.sh

@@ -983,9 +983,10 @@ main() {
   remove_legacy_postgres
 
   section "Waiting For Rollouts"
-  # Critical user-facing services: 600s to absorb any residual image-pull delay
-  # after the pre-pull step (e.g. a node was temporarily unavailable during pre-pull).
-  wait_for_deployment api-ingest     600s
+  # Critical user-facing services: allow residual image-pull or scheduling delay
+  # after the pre-pull step. api-ingest gets a longer window because it is
+  # hard-colocated with the current Postgres primary.
+  wait_for_deployment api-ingest     1800s
   pin_deployment_to_postgres_primary api-ingest
   wait_for_deployment api-dashboard  600s
   wait_for_deployment ingest-upload  600s