From d4155c46117eb1db6255ebac0ea47e6fc3e99801 Mon Sep 17 00:00:00 2001
From: Paul Nothaft <paul@MacStudio-von-Paul.local>
Date: Thu, 14 May 2026 20:35:54 +0200
Subject: [PATCH] fix(install): drop racy migration step + add missing frontend
 container (#484)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Two follow-up fixes inside the same install-experience surface as
the previous commit:

1. **Removed `docker compose exec -T backend npm run migrate`** in
   both install_docker and update_docker_installation. The backend
   container's wait-for-db.sh already runs `npm run migrate:safe`
   on startup; the script was racing it with a separate (and
   non-safe) `npm run migrate`. That race is the most likely
   actual mechanism behind #484's "relation 'photos' does not
   exist" error on the second install attempt — partial schema
   visible to one of the two parallel migrators. Replaced with a
   bounded wait for the backend container to become healthy
   (Docker healthcheck reports green only after wait-for-db.sh
   finishes its migration pass).

2. **Added the missing frontend container** to the script-generated
   compose. The script previously generated a postgres + redis +
   backend stack with no frontend at all (backend on host port
   3001), while the documented production install
   (docker-compose.production.yml) ships postgres + redis +
   backend + frontend (nginx /api proxy on host port 3000). That
   shape divergence is half of issue B in #484 — script-installed
   admins had no frontend container and were left wondering where
   the UI lived. Aligning both compose files on the same shape
   eliminates the divergence; the frontend uses curl in its
   healthcheck (frontend/Dockerfile explicitly `apk add curl`)
   unlike the backend.

The remaining piece of issue B — picking ONE canonical install
path (build-from-source script vs. prebuilt-image production
compose) and deprecating the other — is a deployment-strategy
call that deserves its own design pass. Both paths now produce
architecturally-equivalent stacks.
---
 scripts/picpeak-setup.sh | 65 ++++++++++++++++++++++++++++++++--------
 1 file changed, 52 insertions(+), 13 deletions(-)

diff --git a/scripts/picpeak-setup.sh b/scripts/picpeak-setup.sh
index 3b0d071c..215643d2 100755
--- a/scripts/picpeak-setup.sh
+++ b/scripts/picpeak-setup.sh
@@ -538,9 +538,21 @@ EOF
     log_step "Waiting for services to initialize..."
     sleep 10
 
-    # Run database migrations
-    log_step "Running database migrations..."
-    docker compose exec -T backend npm run migrate
+    # Migrations are run automatically by backend/wait-for-db.sh on
+    # container startup (`npm run migrate:safe`). Running migrate here
+    # in parallel — as we used to — could race against the in-container
+    # migration and leave the schema half-applied (the actual mechanism
+    # behind the "relation 'photos' does not exist" symptom in #484
+    # when re-installing on top of partial state). Wait briefly for the
+    # backend to finish its migrate:safe pass instead.
+    log_step "Waiting for backend to finish migrations and become healthy..."
+    for _ in $(seq 1 30); do
+      if docker inspect -f '{{.State.Health.Status}}' picpeak-backend 2>/dev/null | grep -q '^healthy$'; then
+        log_success "Backend healthy."
+        break
+      fi
+      sleep 2
+    done
 
     if [[ "$FORCE_ADMIN_PASSWORD_RESET" == "true" ]]; then
         log_step "Resetting admin credentials..."
@@ -646,14 +658,32 @@ services:
       timeout: 10s
       retries: 3
 
-  # The legacy separate `workers` container has been removed: as of
-  # the in-process worker consolidation noted in the native systemd
-  # installer below ("Backend service includes workers — fileWatcher,
-  # expirationChecker are started by server.js"), running a second
-  # `npm run workers` container caused two file watchers + two
-  # expiration checkers to compete for the same DB rows. Cleaned up
-  # on existing installs by `picpeak-setup.sh upgrade`, which stops
-  # and removes the picpeak-workers container if found.
+  # Frontend container (#484). Previously absent from the
+  # script-generated compose, which left the script's docker
+  # architecture (backend on host port 3001, no separate frontend)
+  # different from the documented production install
+  # (docker-compose.production.yml: backend internal-only +
+  # frontend nginx serving /api proxy on host port 3000). Aligning
+  # both shapes on the same 3-service shape — postgres + redis +
+  # backend, plus a frontend nginx — eliminates the doc/script
+  # divergence MrGabri flagged.
+  frontend:
+    build: ./frontend
+    container_name: picpeak-frontend
+    ports:
+      - "${FRONTEND_PORT:-3000}:80"
+    networks:
+      - picpeak-network
+    depends_on:
+      - backend
+    restart: unless-stopped
+    healthcheck:
+      # frontend Dockerfile installs curl (apk add --no-cache curl)
+      # — safe to use here unlike the backend.
+      test: ["CMD", "curl", "-f", "http://localhost/health"]
+      interval: 30s
+      timeout: 10s
+      retries: 3
 
 volumes:
   postgres-data:
@@ -1196,8 +1226,17 @@ update_docker_installation() {
 
     docker compose up -d
 
-    # Run migrations
-    docker compose exec -T backend npm run migrate
+    # Migrations are run automatically by backend/wait-for-db.sh on
+    # container startup. Wait for the backend to become healthy
+    # rather than racing it with a manual `npm run migrate`.
+    log_step "Waiting for backend to finish migrations and become healthy..."
+    for _ in $(seq 1 30); do
+      if docker inspect -f '{{.State.Health.Status}}' picpeak-backend 2>/dev/null | grep -q '^healthy$'; then
+        log_success "Backend healthy."
+        break
+      fi
+      sleep 2
+    done
 
     log_success "Docker installation updated successfully!"
 }