mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-09 13:01:00 +00:00
Marc-André Bombeck
b55850967d
The replay cell was keyed on (user, key, method, path). A client that sends two different writes under one key got the first write's cached response for the second, and the second was never saved. Native clients up to 1.1.0 post the two halves of a manual blood pressure exactly that way, so the diastolic value was silently dropped. Each cell now stores a SHA-256 fingerprint of the request body (JSON with recursively sorted keys, otherwise the raw bytes; scoped by method and path; at most the first MiB is read). Lookup replays, or refuses as in flight, only when the fingerprint matches. A different body, or a row written before the column existed, runs the handler without claiming or caching and leaves the existing cell for its own retries; a lost claim race re-checks the winner's fingerprint the same way. The body itself is never stored. Migration 0371 adds the nullable idempotency_keys.request_fingerprint column. The OpenAPI parameter description, the client notes and the Home Assistant guide say what a replay now requires. docs/ops gains a read-only query that lists systolic readings left without their diastolic half, held to the schema by an integration test.
9 lines
570 B
SQL
9 lines
570 B
SQL
-- What request a replay-cache cell answered, as a SHA-256 of the canonical
|
|
-- request body scoped by method and path. A request that reuses a key with a
|
|
-- different body is executed instead of being handed the first body's cached
|
|
-- response. The body itself is never stored. Nullable: rows written before
|
|
-- this release carry none, and a null never matches, so they stop replaying
|
|
-- for anything but their own retries already in flight (they expire within
|
|
-- 24 hours either way).
|
|
ALTER TABLE "idempotency_keys" ADD COLUMN IF NOT EXISTS "request_fingerprint" TEXT;
|