Dire ce qu'il faut faire quand la connexion à la base est refusée

L'application redémarrait en boucle sur « P1000 » sans rien indiquer. Le point
d'entrée distingue désormais les deux causes et donne le remède.

Les deux codes ne disent pas la même chose, et c'est la mesure qui a permis de
les séparer : **P1010** signifie que le rôle n'existe pas, **P1000** qu'il existe
mais que son mot de passe ne correspond pas à celui que porte la pile — le cas
d'un rôle posé lors d'un déploiement antérieur avec une autre valeur. Le remède
est le même : `db-init` crée le rôle ou réaligne son mot de passe.

Le script d'initialisation lui-même a été éprouvé une fois de plus, y compris
avec l'argument parasite que Docker ajoute quand `entrypoint` est surchargé sans
`command` : il aboutit et pose le rôle.

Ce que je ne peux pas voir d'ici, et qu'il faut regarder sur le serveur : si le
service `db-init` figure dans la pile déployée, et ce qu'il a journalisé. Un
rôle dont le mot de passe ne correspond pas est précisément ce qu'il corrige.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv

docker-compose.yml

@@ -105,6 +105,8 @@ services:
       # salarié écrites dans la couche du conteneur disparaîtraient au premier
       # redéploiement, et une pièce d'identité perdue ne se reconstitue pas.
       DOCUMENT_STORE: /data/documents
+      # Sert uniquement au diagnostic affiché quand la connexion est refusée.
+      APP_DB_USER: ${APP_DB_USER:-planflow_app}
     volumes:
       - documents:/data
       # Volume distinct de la base et des documents : sauvegarder l'un ne doit

docker/entrypoint.sh

@@ -57,6 +57,50 @@ export ENCRYPTION_KEY
 # Appelée par son chemin plutôt que par `.bin/prisma` — un lien symbolique
 # recopié d'une image à l'autre est une dépendance de plus à la disposition des
 # fichiers, et c'est exactement ce qui a cassé ici.
-( cd "$MIGRATOR_DIR" && node node_modules/prisma/build/index.js migrate deploy )
+migration_log="$(mktemp)"
+if ! ( cd "$MIGRATOR_DIR" && node node_modules/prisma/build/index.js migrate deploy ) \
+    >"$migration_log" 2>&1; then
+  cat "$migration_log"
+
+  # Deux codes, deux causes voisines, même remède :
+  #   P1010 — le rôle n'existe pas ;
+  #   P1000 — il existe, mais son mot de passe ne correspond pas à celui de la
+  #           pile, typiquement parce qu'il a été posé lors d'un déploiement
+  #           antérieur avec une autre valeur.
+  #
+  # Dans les deux cas c'est `db-init` qui remet les choses d'aplomb : il crée le
+  # rôle ou réaligne son mot de passe. Sans ce message, l'application redémarre
+  # en boucle sur une erreur qui n'indique rien à faire.
+  if grep -qE 'P1000|P1010' "$migration_log"; then
+    role="${APP_DB_USER:-planflow_app}"
+    echo ''
+    echo '════════════════════════════════════════════════════════════════'
+    if grep -q 'P1010' "$migration_log"; then
+      echo " Le rôle « ${role} » n'existe pas dans cette base."
+    else
+      echo " Le rôle « ${role} » existe, mais son mot de passe ne correspond"
+      echo ' pas à celui que porte la pile. Il a probablement été créé lors'
+      echo " d'un déploiement antérieur, avec une autre valeur."
+    fi
+    echo ''
+    echo ' Le service `db-init` crée ce rôle et réaligne son mot de passe à'
+    echo " chaque démarrage. Vérifiez qu'il figure bien dans la pile, et ce"
+    echo " qu'il a journalisé :"
+    echo ''
+    echo '     docker compose logs db-init'
+    echo '     docker compose run --rm db-init'
+    echo ''
+    echo " La seconde commande le rejoue : il est fait pour être exécuté"
+    echo " autant de fois qu'il le faut."
+    echo '════════════════════════════════════════════════════════════════'
+    echo ''
+  fi
+
+  rm -f "$migration_log"
+  exit 1
+fi
+
+cat "$migration_log"
+rm -f "$migration_log"
 
 exec node server.js