Nommer le vrai obstacle : le mot de passe gravé dans le volume

Le diagnostic disait « mot de passe d'amorçage erroné » sans dire pourquoi
cela arrive, et on cherchait du côté du rôle applicatif — qui n'y est pour
rien.

`POSTGRES_PASSWORD` n'est lu qu'à l'initialisation du volume de la base. Un
volume créé lors d'un déploiement antérieur, fût-il un déploiement qui avait
échoué pour une autre raison, garde le mot de passe d'alors ; le changer
dans la pile n'y touche pas, le volume ne se réinitialise jamais. Le compte
d'amorçage est alors refusé, l'application ne peut plus réparer le rôle
applicatif, et le seul symptôme visible est un P1000 qui désigne le mauvais
coupable.

Le message nomme désormais ce cas et donne les deux issues : repartir d'un
volume neuf quand la base est vide, ou réaligner le mot de passe par la
socket locale — que l'image PostgreSQL accepte sans l'ancien.

Éprouvé sur la panne réelle, sous authentification par mot de passe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
This commit is contained in:
Claude committed 2026-08-10 06:25:45 +00:00
1 parent dbb0d68634
commit 90e069f66a
2 files changed
+73 -3

No files matched your search

+45 -3
View File
@@ -106,9 +106,51 @@ try {
} catch (error) {
// Non bloquant : le rôle est peut-être déjà correct et posé par `db-init`.
// Faire échouer le démarrage ici priverait d'une installation qui marche.
console.error(
`[bootstrap] Provisionnement impossible (${error instanceof Error ? error.message : String(error)}).`,
);
const message = error instanceof Error ? error.message : String(error);
console.error(`[bootstrap] Provisionnement impossible (${message}).`);
// Le cas de très loin le plus fréquent, et le moins évident : le compte
// d'amorçage lui-même est refusé.
//
// `POSTGRES_PASSWORD` n'est lu qu'à **l'initialisation du volume**. Un volume
// créé lors d'un déploiement antérieur garde le mot de passe d'alors, et le
// changer dans la pile n'y touche pas — le volume ne se réinitialise jamais.
// Sans cette explication, on cherche indéfiniment du côté du rôle applicatif,
// qui n'y est pour rien.
if (/password authentication failed/i.test(message)) {
console.error('');
console.error(
`[bootstrap] Le compte d’amorçage « ${superUser} » est lui-même refusé.`,
);
console.error(
'[bootstrap] POSTGRES_PASSWORD n’est lu qu’à la création du volume de la',
);
console.error(
'[bootstrap] base. Si ce volume vient d’un déploiement antérieur, il porte',
);
console.error(
'[bootstrap] encore l’ancien mot de passe, et le changer dans la pile n’y',
);
console.error('[bootstrap] change rien.');
console.error('');
console.error('[bootstrap] • Base encore vide — repartir d’un volume neuf :');
console.error('[bootstrap] docker compose down');
console.error('[bootstrap] docker volume rm planflow_db-data');
console.error('[bootstrap] docker compose up -d');
console.error('');
console.error('[bootstrap] • Base à conserver — réaligner le mot de passe.');
console.error(
'[bootstrap] Par la socket locale, qui ne demande pas l’ancien :',
);
console.error(
`[bootstrap] docker compose exec db psql -U ${superUser} \\`,
);
console.error(
`[bootstrap] -c "ALTER USER ${superUser} PASSWORD '<celui de la pile>';"`,
);
console.error('');
}
console.error(
'[bootstrap] La suite dira si le rôle applicatif est utilisable en l’état.',
);