[PR #434] Add startup readiness checks and authenticated tenant readiness endpoint #738

New issue

Open

opened 2026-03-13 21:06:36 +03:00 by kerem · 0 comments

kerem commented

2026-03-13 21:06:36 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/AJaySi/ALwrity/pull/434
Author: @AJaySi
Created: 3/12/2026
Status: 🔄 Open

Base: main ← Head: codex/improve-startup-health-checks-and-readiness-signals

📝 Commits (1)

593110b Add startup readiness checks and tenant auth-context health endpoint

📊 Changes

4 files changed (+325 additions, -14 deletions)

View changed files

📝 backend/app.py (+22 -6)
📝 backend/main.py (+24 -8)
➕ backend/services/startup_health.py (+214 -0)
➕ docs/STARTUP_READINESS_BEHAVIOR.md (+65 -0)

📄 Description

Motivation

Replace using init_database() as the sole readiness signal so startup validates filesystem and tenant DBs in multi-tenant mode.
Make startup failures explicit and optionally fail-fast in production to avoid running in an unknowingly degraded state.
Provide operators a per-tenant readiness check (under auth context) distinct from platform startup health.

Description

Added a shared startup health module backend/services/startup_health.py that verifies the workspace root exists and is writable, validates DB open/create for single-tenant or a tenant (or synthetic) path in multi-tenant, and performs required schema/table+column compatibility checks for baseline migrations using _REQUIRED_SCHEMA (e.g., onboarding_sessions, daily_workflow_plans).
Replaced init_database() as the primary readiness signal in both backend/main.py and backend/app.py by calling run_startup_health_routine() during application startup and logging errors explicitly, and re-raising to enable fail-fast behavior when configured.
Added an authenticated readiness endpoint GET /health/readiness (in both entrypoints) that returns the latest startup report via get_startup_status() and a per-tenant auth-context check via readiness_under_auth_context() which resolves the tenant DB path and attempts a session/query.
Added operator documentation docs/STARTUP_READINESS_BEHAVIOR.md describing single-tenant vs multi-tenant expectations, warning vs failure conditions, and the ALWRITY_FAIL_FAST_STARTUP / production default semantics.

Testing

Compiled the modified modules with python -m py_compile backend/services/startup_health.py backend/main.py backend/app.py which succeeded.
Executed the startup routine interactively via run_startup_health_routine() which exercised DB initialization paths and reported a failed status in this environment due to the workspace root not existing (this is environment-dependent and expected in a clean test container); the routine logged errors and warnings as designed.
No unit tests were added; behaviour validated via static compile and a runtime invocation of run_startup_health_routine().

Codex Task

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/AJaySi/ALwrity/pull/434 **Author:** [@AJaySi](https://github.com/AJaySi) **Created:** 3/12/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `codex/improve-startup-health-checks-and-readiness-signals` --- ### 📝 Commits (1) - [`593110b`](https://github.com/AJaySi/ALwrity/commit/593110bbec83f095a9202f98fcbd07eda82be9a2) Add startup readiness checks and tenant auth-context health endpoint ### 📊 Changes **4 files changed** (+325 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `backend/app.py` (+22 -6) 📝 `backend/main.py` (+24 -8) ➕ `backend/services/startup_health.py` (+214 -0) ➕ `docs/STARTUP_READINESS_BEHAVIOR.md` (+65 -0) </details> ### 📄 Description ### Motivation - Replace using `init_database()` as the sole readiness signal so startup validates filesystem and tenant DBs in multi-tenant mode. - Make startup failures explicit and optionally fail-fast in production to avoid running in an unknowingly degraded state. - Provide operators a per-tenant readiness check (under auth context) distinct from platform startup health. ### Description - Added a shared startup health module `backend/services/startup_health.py` that verifies the workspace root exists and is writable, validates DB open/create for single-tenant or a tenant (or synthetic) path in multi-tenant, and performs required schema/table+column compatibility checks for baseline migrations using `_REQUIRED_SCHEMA` (e.g., `onboarding_sessions`, `daily_workflow_plans`). - Replaced `init_database()` as the primary readiness signal in both `backend/main.py` and `backend/app.py` by calling `run_startup_health_routine()` during application startup and logging errors explicitly, and re-raising to enable fail-fast behavior when configured. - Added an authenticated readiness endpoint `GET /health/readiness` (in both entrypoints) that returns the latest startup report via `get_startup_status()` and a per-tenant auth-context check via `readiness_under_auth_context()` which resolves the tenant DB path and attempts a session/query. - Added operator documentation `docs/STARTUP_READINESS_BEHAVIOR.md` describing single-tenant vs multi-tenant expectations, warning vs failure conditions, and the `ALWRITY_FAIL_FAST_STARTUP` / production default semantics. ### Testing - Compiled the modified modules with `python -m py_compile backend/services/startup_health.py backend/main.py backend/app.py` which succeeded. - Executed the startup routine interactively via `run_startup_health_routine()` which exercised DB initialization paths and reported a `failed` status in this environment due to the workspace root not existing (this is environment-dependent and expected in a clean test container); the routine logged errors and warnings as designed. - No unit tests were added; behaviour validated via static compile and a runtime invocation of `run_startup_health_routine()`. ------ [Codex Task](https://chatgpt.com/codex/tasks/task_e_69b28810816c83289375f3d1ff4176a2) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem added the

pull-request

label

2026-03-13 21:06:36 +03:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ALwrity#738

No description provided.

Rows
Columns