mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-09 21:10:59 +00:00
Marc-André Bombeck
f92e644154
Bundles the deferred v1.4.47 Mediums + Lows with the v1.4.48-deferred items into a single release. Headline: server-side suppression of MEDICATION_REMINDER APNs for iOS clients that own their local reminders (closes GH #206), a push_attempts table backing /api/admin/notifications/diagnostic, and a sweep of v1.4.48 QA forward-findings. Performance (the user-visible win): - /api/analytics cold-fallback path splits the heavy single-statement aggregate into two parallel queries. The linearly composable columns (count / min / max / mean) keep the full-partition scan; the windowed 7 / 30 / 90-day avg / slope / r² columns take a 90-day outer cap so the planner does an index range scan on (user_id, type, measured_at) instead of a full-partition sequential scan. Output is bit-identical; cold slim slice drops from multi-second to sub-second on tenants with large measurement partitions. Server-side notifications: - GET + PATCH /api/auth/me/notification-prefs with deep-merge semantics. Initial category medication.clientManaged: boolean (default false). Cron medicationReminderJob skips dose-due APNs when the flag is true, emitting a medication_reminder.suppressed_client_managed wide-event annotation per skip. - push_attempts table backs the diagnostic endpoint. Every APNS / Web-Push / Telegram / NTFY sender writes a fire-and-forget row. Daily 03:35 Europe/Berlin cleanup prunes rows older than 90 days. - /api/admin/notifications/diagnostic — admin-only endpoint surfacing device APNs token presence (masked), channel config presence, and recent push attempts. Registered in OpenAPI. - Per-channel APNs "Send test" button now fires with eventType: "MEDICATION_REMINDER" so the dispatcher's time-sensitive + priority-10 branch runs. A successful self-test now exercises the exact path production reminders take; an unsuccessful one points the user at iOS Settings → Time Sensitive Notifications rather than appearing to be a server-side bug. Withings reliability: - OAuth callback consumes the nonce atomically (delete-first with P2025 catch for the replay branch). The previous read-then-delete pattern allowed a race between two concurrent callbacks. - ?reason=state redirect differentiated into csrf1 / replay / expired / cross_user so operators can tell mismatch types apart without DB shell access. - connect endpoint rate-limited to 10/60s/user; row-create failures redirect to a consistent error surface. Observability hardening: - redactSensitiveFields(body) denylist helper covers password / token / secret / apiKey / authorization / csrfState / nonce, recursive, case-insensitive. Caught: /api/devices invalid_format issues were echoing apnsToken values verbatim into the audit log. - sanitiseZodIssues(issues, { stripValuesFromMessage: true }) overload applied to 14 audit-log sites. Migrations: 0079 (notification_prefs), 0080 (push_attempts). Tests: 4815 → 5272 unit + integration. Workout-batch integration suite that had been red on main since v1.4.45 (three release commits shipped through it) now green again — updated to match v1.4.42 cross-source dedup semantics. Resolves PR #207.
63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
# Deploy ordering
|
|
|
|
Coolify handles the standard deploy ordering automatically: the
|
|
container image is pulled, `docker-entrypoint.sh` runs
|
|
`prisma migrate deploy` against the live database, and only then does
|
|
the Next.js process bind to the listener. This page documents the
|
|
ordering explicitly for manual-rollback and partial-deploy scenarios
|
|
where the operator drives the steps by hand.
|
|
|
|
## Migration ordering
|
|
|
|
Migrations land **before** the new app container takes traffic. The
|
|
canonical command sequence on a single-instance host:
|
|
|
|
```sh
|
|
# 1. Pull the new image.
|
|
docker pull ghcr.io/marc-bombeck/healthlog:vX.Y.Z
|
|
|
|
# 2. Run migrations against the live DB using the new image.
|
|
docker run --rm --env-file .env.production \
|
|
ghcr.io/marc-bombeck/healthlog:vX.Y.Z \
|
|
pnpm prisma migrate deploy
|
|
|
|
# 3. Recreate the app container so it picks up the new image.
|
|
docker compose up -d app
|
|
```
|
|
|
|
The entrypoint also runs `prisma migrate deploy` on container boot, so
|
|
step 2 is redundant in normal Coolify flow. It's listed explicitly for
|
|
the manual case so an operator can verify the migration result before
|
|
flipping traffic.
|
|
|
|
### What goes wrong if you reverse it
|
|
|
|
If the new app container starts before migrations run, the legacy
|
|
schema is missing the columns / indexes / enum values the new code
|
|
expects. Symptoms: Prisma client throws `P2022 column does not exist`
|
|
on the first query that touches the new shape, the request path 500s,
|
|
and the dispatcher logs fill with the same error until the migration
|
|
catches up. Health checks usually keep the container marked "healthy"
|
|
because `/api/version` doesn't exercise the affected tables — so a
|
|
naïve load balancer will happily route real traffic into the broken
|
|
shell.
|
|
|
|
### Rollback
|
|
|
|
Rolling back **migrations** is generally one-way. Prisma's migration
|
|
history table tracks applied migrations by hash; the `down` step is
|
|
not auto-generated and most HealthLog migrations are forward-only
|
|
(column drops, enum additions, index rebuilds). If a release has to
|
|
roll back:
|
|
|
|
1. Roll back the **app container** to the previous image tag.
|
|
2. Leave the **database schema** at the newer migration. The previous
|
|
app version reads forward-compatible-ish shapes for nearly every
|
|
release pair we've shipped on the v1.4.x line; tested in the
|
|
release-marathon QA pass.
|
|
3. If a column-drop migration ships in the rollback target, hand-roll
|
|
the column back via a fresh forward migration (`pnpm prisma migrate
|
|
dev --create-only --name vX_Y_Z_rollback_<col>`), edit the SQL,
|
|
commit, and re-deploy. Never `migrate resolve --rolled-back` against
|
|
production unless you've taken a fresh `pg_dump` first.
|