Verificarea de sănătate dovedește că baza de date răspunde
GET /api/health întorcea {status:'ok'} fără să atingă baza de date. Docker
decide starea containerului de backend din acest răspuns, iar frontend-ul pornește
abia după ce starea e sănătoasă (depends_on: condition: service_healthy, în ambele
fișiere compose). Un răspuns care dovedea doar că procesul trăiește lăsa magazinul
să se deschidă gol — fișier de bază lipsă, volum nemontat, sqlite corupt — în timp
ce fiecare sondă raporta verde.
Ce se schimbă
-
backend/src/routes/health.tsruleazăprisma.$queryRaw\SELECT 1`înainte de răspuns. Reușită → 200{status:'ok'}, formă neschimbată (tests/smoke.test.tso fixa deja). Eșec → 503{status:'degraded'}`, cu o singură linie la nivel de eroare în jurnal; mesajul Prisma, care conține calea bazei, nu ajunge în răspuns. -
backend/tests/health.test.tsacoperă ambele drumuri. Ramura de eșec se atinge făcând interogarea să arunce, nu stricând baza de test, pe care o împarte tot rulajul. - Bloc
logging:(json-file,max-size: 10m,max-file: 5) la toate cele patru servicii dindocker-compose.ymlșidocker-compose.prod.yml: plafon de 50 MB de jurnal per container, cu rotație. Până acum nu exista nicio limită scrisă de noi, iar driverul implicit păstrează fiecare linie la nesfârșit.
Blocurile healthcheck: rămân neatinse. Interogarea nu întârzie un deploy curat:
comanda containerului aplică migrările (prisma migrate deploy) înainte ca serverul
să înceapă să răspundă.
Verificări
-
backend/:npm run buildfără ieșire;npm test→ 44 fișiere, 625 teste trecute -
docker compose configpe ambele fișiere → exit 0,max-size/max-fileprezente la ambele servicii în fiecare - Dovadă pe server local pornit:
curl -i http://localhost:3001/api/health→ 200{"status":"ok"}; repornit cuDATABASE_URLspre un volum inexistent → 503{"status":"degraded"}, cu eroarea în jurnal
NEVERIFICAT, ca în issue: dacă /etc/docker/daemon.json de pe serverul de producție
impune deja limite globale de jurnal. E infrastructură care nu se vede din repo.
Closes #28 (closed)