Admin
f055700c2d
The subscribe token is minted once per alert and lives as long as it does; subscribers are never evicted, so the rotation counter had no reader. Drop token_version from the schema and stop serialising tokenVersion on the wire. The QR payload is now built from alert id + token only, which also makes it instance-relative.
28 lines
1.2 KiB
SQL
28 lines
1.2 KiB
SQL
\c dcntrlized;
|
|
|
|
-- 002_drop_token_version.sql — remove the rotation counter.
|
|
--
|
|
-- Contract decision (2026-10-18): `rotateSubscribeToken` is gone. The subscribe
|
|
-- token is minted once at creation and lives as long as the alert; subscribers
|
|
-- are never evicted and there is no rotation lifecycle. `token_version` was the
|
|
-- rotation counter and has no remaining reader: no query, view or wire field
|
|
-- depends on it (the API stopped serialising `tokenVersion` in the same change).
|
|
--
|
|
-- `001_alarm_schema.sql` is already applied to the dev database and is never
|
|
-- edited in place, so the column is dropped here instead of being removed from
|
|
-- the CREATE TABLE. A fresh database applies 001 (which still creates the
|
|
-- column) and immediately drops it below; that is intentional and keeps the
|
|
-- migration history append-only. The CHECK constraint
|
|
-- `alerts_token_version_positive` disappears with the column.
|
|
--
|
|
-- Idempotent: guarded on the schema/column existing, so re-applying the whole
|
|
-- sequence (or applying this file alone to a virgin database) is a clean no-op.
|
|
|
|
DO $$
|
|
BEGIN
|
|
IF EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'alarm') THEN
|
|
ALTER TABLE alarm.alerts DROP COLUMN IF EXISTS token_version;
|
|
END IF;
|
|
END
|
|
$$;
|