[Decision]: Review current - Persistence adapter health - Where to fail

[juscghwe]

Decision question

Which missing config should lead to a hard or soft fail of the backend creation?
Which config imports should come from docker-compose (for dev) and which from inside the container?

Context

• /backend/src/persistence relies on ENV variables to be setup and there should be distinction between failing rough and gracefully.
• /backend/src/health should return meaningful info as long as possible till the ENV config is so messed up, the backend is impossible to load. This makes debugging more easier and can help installation debugging.

Example

When we later add real medication routes, those should fail closed if persistence is unhealthy:

GET /api/medications -> 503 SERVICE_UNAVAILABLE

because the backend process is alive, but the app cannot serve state safely.

Options considered

Will be put down later.

Trade-offs

No response

Proposed decision

Current decision:

All context is loaded through sqlite-adapter and handled there for now (see reason for further insight).

Reason:

Backend should start if persistence config is broken, because otherwise it cannot report what’s broken.

Eg:

missing DB_PATH
missing SQLITE_JOURNAL_MODE
invalid SQLITE_JOURNAL_MODE
SQLite open failed

should result in:

/api/health/runtime -> 200 healthy
/api/health/persistence -> 503 unhealthy
/api/health -> 503 unhealthy

Impact

API, backend, testing, deployment

Revisit conditions

• Before hammering down more API endpoints in M4