mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-15 23:12:04 +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.
50 lines
2.1 KiB
TypeScript
50 lines
2.1 KiB
TypeScript
/**
|
|
* v1.4.48 M1 — boot-time probe for legacy `IntegrationStatus` rows that
|
|
* still carry `consecutiveFailuresByKind: NULL`.
|
|
*
|
|
* v1.4.47 W1 dropped the single-column `consecutiveFailures` integer in
|
|
* favour of the per-kind JSON bucket. The alert-ladder reads
|
|
* `Math.max(...Object.values(buckets))` against the threshold — but a
|
|
* row that survives with the JSON column still NULL deterministically
|
|
* counts as `max([1]) = 1` on its first failure (the fall-back signal
|
|
* the writer emits when the row is absent), so the operator notices
|
|
* two strikes later than they did pre-v1.4.47 where the legacy column
|
|
* back-stopped the maths.
|
|
*
|
|
* Operator judgement ("every active row has been written under
|
|
* v1.4.43+, so the column is non-null") is not a code invariant. This
|
|
* probe is the runtime version of that invariant: one count query at
|
|
* worker boot, a single Wide-Event warning if any such row survives.
|
|
* Fire-and-forget — a probe failure must never block boot. Idempotent
|
|
* across reboots.
|
|
*/
|
|
import type { PrismaClient } from "@/generated/prisma/client";
|
|
import { annotate, getEvent } from "@/lib/logging/context";
|
|
|
|
interface IntegrationStatusNullProbeResult {
|
|
count: number;
|
|
}
|
|
|
|
type PrismaCountClient = Pick<PrismaClient, "$queryRaw">;
|
|
|
|
export async function probeIntegrationStatusNullBuckets(
|
|
prisma: PrismaCountClient,
|
|
): Promise<IntegrationStatusNullProbeResult> {
|
|
// Prisma's typed `count` rejects a literal `null` against a `Json?`
|
|
// column without going through `Prisma.JsonNullValueFilter`. The raw
|
|
// `IS NULL` is the simpler shape and matches the backlog spec.
|
|
const rows = await prisma.$queryRaw<Array<{ count: bigint }>>`
|
|
SELECT COUNT(*)::bigint AS count
|
|
FROM integration_statuses
|
|
WHERE consecutive_failures_by_kind IS NULL
|
|
`;
|
|
const count = Number(rows[0]?.count ?? 0);
|
|
if (count > 0) {
|
|
getEvent()?.addWarning(
|
|
`[integration-status-null-probe] ${count} row(s) still carry consecutiveFailuresByKind=NULL; alert ladder will trip two strikes late until they are rewritten`,
|
|
);
|
|
annotate({ meta: { integration_status_null_buckets: count } });
|
|
}
|
|
return { count };
|
|
}
|