Ajouter un healthcheck Logto à l'API health #1

New issue

Closed

opened 2026-04-11 18:09:52 +00:00 by maximus · 0 comments

maximus commented

2026-04-11 18:09:52 +00:00

Owner

Contexte

Le dashboard admin de la-compagnie-maximus monitore deja Logto cote client (issue #71, PR #78). L'ajout d'un check serveur-side dans vps-health-api donne une source de verite cross-VPS, independante du navigateur utilisateur, et exploitable par d'autres consommateurs (defenseurs, monitoring externe).

Decisions (analyse du 2026-04-21)

URL configurable via env var LOGTO_HEALTH_URL (default https://auth.lacompagniemaximus.com/oidc/.well-known/openid-configuration)
/health retourne toujours HTTP 200 — le statut de Logto est dans le body (logto.status)
Timeout borne a 3000 ms via AbortController
Parallelisation : Promise.all([getCpuPercent(), getLogtoHealth()]) pour eviter d'additionner les latences (CPU sample = 500ms, Logto timeout <= 3000ms)

Taches

getLogtoHealth() dans index.js : fetch natif Node 22 + AbortController(3000ms) + mesure performance.now()
Convertir getHealth() en async, paralleliser avec getCpuPercent() via Promise.all
Ajouter logto: { status: "up"|"down", responseTimeMs: number, error?: string } dans la reponse /health
Mettre a jour .env.example avec LOGTO_HEALTH_URL
Documenter le nouveau champ dans CLAUDE.md (section Endpoints)

Fichiers concernes

index.js — nouvelle fonction + handler async
.env.example — nouvelle var
CLAUDE.md — doc du champ logto

Criteres d'acceptation

curl -H "Authorization: Bearer $TOKEN" /health | jq .logto retourne {status, responseTimeMs, error?}
Timeout borne a 3s (aucun blocage au-dela)
/health reste HTTP 200 meme si Logto est down
Latence totale /health ~= max(500ms CPU sample, 3000ms timeout Logto), pas la somme

Complexite estimee

Simple (~25 lignes, un seul fichier, Node 22 fetch natif).

References

Issue source : maximus/la-compagnie-maximus#71
PR cote client : maximus/la-compagnie-maximus#78
Spec : spec-audit-logto.md (V9)

## Contexte Le dashboard admin de la-compagnie-maximus monitore deja Logto cote client (issue #71, PR #78). L'ajout d'un check serveur-side dans `vps-health-api` donne une source de verite cross-VPS, independante du navigateur utilisateur, et exploitable par d'autres consommateurs (defenseurs, monitoring externe). ## Decisions (analyse du 2026-04-21) - URL configurable via env var `LOGTO_HEALTH_URL` (default `https://auth.lacompagniemaximus.com/oidc/.well-known/openid-configuration`) - `/health` retourne toujours HTTP 200 — le statut de Logto est dans le body (`logto.status`) - Timeout borne a 3000 ms via `AbortController` - Parallelisation : `Promise.all([getCpuPercent(), getLogtoHealth()])` pour eviter d'additionner les latences (CPU sample = 500ms, Logto timeout <= 3000ms) ## Taches - [ ] `getLogtoHealth()` dans `index.js` : fetch natif Node 22 + AbortController(3000ms) + mesure `performance.now()` - [ ] Convertir `getHealth()` en async, paralleliser avec `getCpuPercent()` via `Promise.all` - [ ] Ajouter `logto: { status: "up"|"down", responseTimeMs: number, error?: string }` dans la reponse `/health` - [ ] Mettre a jour `.env.example` avec `LOGTO_HEALTH_URL` - [ ] Documenter le nouveau champ dans `CLAUDE.md` (section Endpoints) ## Fichiers concernes - `index.js` — nouvelle fonction + handler async - `.env.example` — nouvelle var - `CLAUDE.md` — doc du champ `logto` ## Criteres d'acceptation - [ ] `curl -H "Authorization: Bearer $TOKEN" /health | jq .logto` retourne `{status, responseTimeMs, error?}` - [ ] Timeout borne a 3s (aucun blocage au-dela) - [ ] `/health` reste HTTP 200 meme si Logto est down - [ ] Latence totale `/health` ~= max(500ms CPU sample, 3000ms timeout Logto), pas la somme ## Complexite estimee Simple (~25 lignes, un seul fichier, Node 22 fetch natif). ## References - Issue source : maximus/la-compagnie-maximus#71 - PR cote client : maximus/la-compagnie-maximus#78 - Spec : `spec-audit-logto.md` (V9)