docs: record postgres health store modes

This commit is contained in:
Siavash Sameni
2026-06-01 14:00:16 +04:00
parent 7b5dbb2683
commit 5352a78e96
3 changed files with 39 additions and 7 deletions

View File

@@ -3,12 +3,12 @@ title: Postgres Runtime Cutover Status
tags: [data-model, postgres, migration, runtime-status] tags: [data-model, postgres, migration, runtime-status]
aliases: [Postgres Status, PG Cutover Status, Mongo vs Postgres Runtime] aliases: [Postgres Status, PG Cutover Status, Mongo vs Postgres Runtime]
created: 2026-05-31 created: 2026-05-31
source: backend integrate-main-into-development@1757f1e source: backend integrate-main-into-development@ea43862
--- ---
# Postgres Runtime Cutover Status # Postgres Runtime Cutover Status
> **Current branch:** backend `integrate-main-into-development` at `1757f1e`, version `2.8.9`. > **Current branch:** backend `integrate-main-into-development` at `ea43862`, version `2.8.11`.
> >
> **Bottom line:** this branch is **Postgres-capable**, not fully Postgres-backed. Auth-owned user data can run through Postgres when `AUTH_STORE=postgres`; confirmation-threshold runtime config/history can run through Postgres when `CONFIG_STORE=postgres`; user address CRUD can run through Postgres when `ADDRESS_STORE=postgres`; marketplace categories, level config, shop settings, and reviews can run through Postgres with their own store flags. All PG-backed stores require `PG_URL`. Mongo remains the default and the compatibility store for still-Mongo domains. > **Bottom line:** this branch is **Postgres-capable**, not fully Postgres-backed. Auth-owned user data can run through Postgres when `AUTH_STORE=postgres`; confirmation-threshold runtime config/history can run through Postgres when `CONFIG_STORE=postgres`; user address CRUD can run through Postgres when `ADDRESS_STORE=postgres`; marketplace categories, level config, shop settings, and reviews can run through Postgres with their own store flags. All PG-backed stores require `PG_URL`. Mongo remains the default and the compatibility store for still-Mongo domains.
@@ -16,8 +16,9 @@ source: backend integrate-main-into-development@1757f1e
| Area | Runtime status | Notes | | Area | Runtime status | Notes |
|---|---|---| |---|---|---|
| Postgres connection | Available when `PG_URL` is set | Current runtime code uses `src/infrastructure/postgres/client.ts`; there is no `src/db/` Drizzle layer in this checkout. | | Postgres connection | Available when `PG_URL` is set | Current store facades use `src/infrastructure/postgres/client.ts`; the broader `src/db/` Drizzle layer and repository factory exist, but most live services are not wired through that factory yet. |
| Runtime schema bootstrap | Implemented for auth, config, address, and reference stores | Auth tables are bootstrapped from `src/services/auth/postgresAuthSchema.ts`; store facades bootstrap their own tables at startup when their `*_STORE=postgres` flag is enabled. | | Runtime schema bootstrap | Implemented for auth, config, address, and reference stores | Auth tables are bootstrapped from `src/services/auth/postgresAuthSchema.ts`; store facades bootstrap their own tables at startup when their `*_STORE=postgres` flag is enabled. |
| Health observability | Implemented in `/api/health` | `checks.postgres` reports `configured`, `required`, `storeModes`, `enabledStores`, and `enabledStoreCount`, so Gatus/operators can verify both PG reachability and which runtime stores are actively PG-backed. |
| Auth-owned user store | Opt-in with `AUTH_STORE=postgres` | Auth, passkey, Telegram auth/link/session/temp-verification, and `/api/user` profile paths use an auth-store facade. In PG mode, users are stored in Postgres and mirrored back to Mongo through `legacy_object_id` for compatibility with still-Mongo services. | | Auth-owned user store | Opt-in with `AUTH_STORE=postgres` | Auth, passkey, Telegram auth/link/session/temp-verification, and `/api/user` profile paths use an auth-store facade. In PG mode, users are stored in Postgres and mirrored back to Mongo through `legacy_object_id` for compatibility with still-Mongo services. |
| Confirmation-threshold runtime config | Opt-in with `CONFIG_STORE=postgres` | `ConfigSetting` / `ConfigSettingHistory` access for `/api/admin/settings/confirmation-thresholds` and transaction-safety confirmation thresholds uses a config-store facade. PG-mode writes mirror back to Mongo for rollback. | | Confirmation-threshold runtime config | Opt-in with `CONFIG_STORE=postgres` | `ConfigSetting` / `ConfigSettingHistory` access for `/api/admin/settings/confirmation-thresholds` and transaction-safety confirmation thresholds uses a config-store facade. PG-mode writes mirror back to Mongo for rollback. |
| User addresses | Opt-in with `ADDRESS_STORE=postgres` | `/api/addresses` CRUD uses an address-store facade. PG mode enforces one primary address per user with a partial unique index and mirrors writes/deletes back to Mongo for rollback. | | User addresses | Opt-in with `ADDRESS_STORE=postgres` | `/api/addresses` CRUD uses an address-store facade. PG mode enforces one primary address per user with a partial unique index and mirrors writes/deletes back to Mongo for rollback. |
@@ -25,7 +26,7 @@ source: backend integrate-main-into-development@1757f1e
| Level configuration | Opt-in with `LEVEL_CONFIG_STORE=postgres` | `PointsService` level reads use a level-config facade. `PointTransaction` and user points remain Mongo-backed. | | Level configuration | Opt-in with `LEVEL_CONFIG_STORE=postgres` | `PointsService` level reads use a level-config facade. `PointTransaction` and user points remain Mongo-backed. |
| Shop settings | Opt-in with `SHOP_SETTINGS_STORE=postgres` | Shop settings controller, seller payment rail resolution, and review enable/disable checks use a shop-settings facade. PG-mode writes mirror back to Mongo. | | Shop settings | Opt-in with `SHOP_SETTINGS_STORE=postgres` | Shop settings controller, seller payment rail resolution, and review enable/disable checks use a shop-settings facade. PG-mode writes mirror back to Mongo. |
| Marketplace reviews | Opt-in with `REVIEW_STORE=postgres` | Review list/summary/create routes use a review-store facade. PG-mode list responses still hydrate `reviewerId` from the user mirror to preserve frontend shape. | | Marketplace reviews | Opt-in with `REVIEW_STORE=postgres` | Review list/summary/create routes use a review-store facade. PG-mode list responses still hydrate `reviewerId` from the user mirror to preserve frontend shape. |
| Repository implementations | Not present in current checkout | The old Drizzle plan still describes the target architecture, but this branch's actual cutover work is currently store-specific raw PG facades. | | Repository implementations | Present but partial runtime wiring | `src/db/repositories/*` and Drizzle schemas exist for the target architecture, but this branch's live cutover work is still mostly store-specific raw PG facades plus the conditional oracle quote write path. |
| Oracle quote persistence | Conditional runtime PG write | `/api/payment/request-network/intents` lazily imports `quoteRepo` only when `ORACLE_QUOTING_ENABLED=true`; it writes `payment_quotes` if the PG parent payment row exists, mirrors to Mongo `Payment.quote`, and records `pg_dualwrite_gaps` if PG is behind. | | Oracle quote persistence | Conditional runtime PG write | `/api/payment/request-network/intents` lazily imports `quoteRepo` only when `ORACLE_QUOTING_ENABLED=true`; it writes `payment_quotes` if the PG parent payment row exists, mirrors to Mongo `Payment.quote`, and records `pg_dualwrite_gaps` if PG is behind. |
| Backfill/verify scripts | Available as operator tooling | `MIGRATION_PG_URL` drives backfill scripts; guards restrict allowed target hosts. These scripts are not run automatically by app startup. | | Backfill/verify scripts | Available as operator tooling | `MIGRATION_PG_URL` drives backfill scripts; guards restrict allowed target hosts. These scripts are not run automatically by app startup. |

View File

@@ -14,14 +14,14 @@ What's instrumented today and what to watch. Today's stack is intentionally lean
Two paths are registered (both are public, rate-limited, not auth-gated): Two paths are registered (both are public, rate-limited, not auth-gated):
- `GET /health` — simple ping used by Docker healthchecks. Returns `200 { success, message, timestamp, environment, version }`. Does **not** probe MongoDB or Redis. - `GET /health` — simple ping used by Docker healthchecks. Returns `200 { success, message, timestamp, environment, version }`. Does **not** probe MongoDB or Redis.
- `GET /api/health` — deep health check added in commit `44579d6` (backend v2.6.49). Calls `runHealthChecks` from `backend/src/services/health/healthCheckService.ts`. Probes MongoDB, Postgres, Redis, Request Network registry data, and Request Network API reachability. Returns `503` only when `report.status === 'down'`. As of backend `2.8.9`, Postgres is a hard dependency only when at least one `*_STORE=postgres` flag is enabled; otherwise an unconfigured Postgres check is reported as skipped. - `GET /api/health` — deep health check added in commit `44579d6` (backend v2.6.49). Calls `runHealthChecks` from `backend/src/services/health/healthCheckService.ts`. Probes MongoDB, Postgres, Redis, Request Network registry data, and Request Network API reachability. Returns `503` only when `report.status === 'down'`. As of backend `2.8.11`, Postgres is a hard dependency only when at least one `*_STORE=postgres` flag is enabled; otherwise an unconfigured Postgres check is reported as skipped. The Postgres check also reports active store modes so monitoring can distinguish "PG is reachable" from "this runtime is actually using PG-backed stores".
`GET /api/health` response shape (from `healthCheckService`): `GET /api/health` response shape (from `healthCheckService`):
```json ```json
{ {
"status": "ok", "status": "ok",
"version": "2.6.xx", "version": "2.8.11",
"timestamp": "...", "uptimeSec": 662,
"checks": { "checks": {
"db": { "ok": true, "latencyMs": 4 }, "db": { "ok": true, "latencyMs": 4 },
"postgres": { "postgres": {
@@ -29,6 +29,25 @@ Two paths are registered (both are public, rate-limited, not auth-gated):
"latencyMs": 5, "latencyMs": 5,
"configured": true, "configured": true,
"required": true, "required": true,
"storeModes": {
"auth": "postgres",
"config": "postgres",
"address": "postgres",
"category": "postgres",
"levelConfig": "postgres",
"shopSettings": "postgres",
"review": "postgres"
},
"enabledStores": [
"auth",
"config",
"address",
"category",
"levelConfig",
"shopSettings",
"review"
],
"enabledStoreCount": 7,
"database": "amanat_dev", "database": "amanat_dev",
"user": "amanat" "user": "amanat"
}, },

View File

@@ -11,6 +11,18 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
--- ---
### 2026-06-01 — backend@ea43862, frontend@b4ea7c9 — expose Postgres store modes in health
**Commits:** backend `ea43862`, frontend `b4ea7c9` (backend `2.8.11`, frontend `2.8.11`)
**Touched:**
- Backend: `src/infrastructure/postgres/client.ts`, `src/services/health/healthCheckService.ts`, `__tests__/postgres-client.test.ts`, `package.json`, `package-lock.json`
- Frontend: `package.json`, `Dockerfile` version metadata only.
**Why:** Phase 0 of the Postgres cutover needed runtime visibility before moving another domain. `/api/health` now reports `checks.postgres.storeModes`, `enabledStores`, and `enabledStoreCount` while preserving the existing `configured`/`required`/status semantics. This lets Gatus and operators verify which opt-in stores are actually PG-backed in dev. Backend was rebased on Mojtaba's `2be91d2` authStore fix before push.
**Verification:** Backend `npm test -- --runTestsByPath __tests__/postgres-client.test.ts`; backend `npm run typecheck -- --pretty false`; backend `npm run build`; backend focused health smoke against local Mongo/Redis containers and `escrow-pgmig-test` Postgres asserted all seven enabled PG stores in `checks.postgres`; frontend `npx tsc --noEmit --ignoreDeprecations 6.0`; backend/frontend `git diff --check`.
**Linked docs updated:** [[Monitoring]], [[Postgres Runtime Cutover Status]]
---
### 2026-06-01 — backend@1757f1e, frontend@600dd0d, deployment@6db02b0 — Postgres runtime cutover stores and health monitoring ### 2026-06-01 — backend@1757f1e, frontend@600dd0d, deployment@6db02b0 — Postgres runtime cutover stores and health monitoring
**Commits:** backend `1757f1e`, frontend `600dd0d`, deployment `6db02b0` (backend `2.8.9`, frontend `2.8.9`) **Commits:** backend `1757f1e`, frontend `600dd0d`, deployment `6db02b0` (backend `2.8.9`, frontend `2.8.9`)