tasq/supabase/migrations/20260322220000_fix_announcement_banner_enqueue.sql

85 lines
3.9 KiB
PL/PgSQL

-- Fix: eliminate double push notifications for announcement banners.
--
-- Root causes addressed:
-- 1. scheduled_for = now() made rows immediately eligible. Multiple consecutive
-- epoch rows (e.g. E and E+1) all had scheduled_for in the past, so all were
-- eligible simultaneously. ON CONFLICT DO NOTHING kept the old rows intact
-- (didn't update scheduled_for to the future), so every processBatch run
-- found 2+ eligible rows → 2+ FCM sends.
-- Fix A (SQL): scheduled_for = start of the NEXT epoch window (future).
-- Fix B (SQL): one-time DELETE of all pre-existing stale rows so the queue
-- starts clean. The edge function deduplication (Fix C) also
-- guards against any future accumulation.
-- Fix C (TS): processBatch deduplicates announcement_banner rows by
-- (announcement_id, user_id), keeping only the highest-epoch
-- row and marking stale ones processed without sending FCM.
--
-- 2. epoch < v_epoch (too aggressive) deleted epoch E's row at the start of
-- epoch E+1 — the row that was due RIGHT NOW — stopping all notifications.
-- Fix: epoch < v_epoch - 1 keeps epoch E intact for processing.
-- ============================================================================
-- One-time cleanup: mark all pre-existing stale announcement_banner rows as
-- processed so they are no longer eligible. These were inserted with the old
-- scheduled_for = now() logic and have scheduled_for in the past, causing them
-- to appear in every processBatch query and generate duplicate pushes.
-- ============================================================================
DELETE FROM public.scheduled_notifications
WHERE notify_type = 'announcement_banner'
AND processed = false;
CREATE OR REPLACE FUNCTION public.enqueue_announcement_banner_notifications()
RETURNS void LANGUAGE plpgsql AS $$
DECLARE
ann RECORD;
usr RECORD;
v_epoch int;
BEGIN
FOR ann IN
SELECT a.id, a.author_id, a.visible_roles, a.push_interval_minutes
FROM public.announcements a
WHERE a.banner_enabled = true
AND a.push_interval_minutes IS NOT NULL
AND a.is_template = false
AND (a.banner_show_at IS NULL OR a.banner_show_at <= now())
AND (a.banner_hide_at IS NULL OR a.banner_hide_at > now())
LOOP
-- One epoch per interval window; prevents duplicate pushes within the window.
v_epoch := FLOOR(
EXTRACT(EPOCH FROM now()) / (ann.push_interval_minutes * 60)
)::int;
-- Purge rows that are ≥2 epochs stale (unprocessed due to missed cycles).
-- We keep epoch = v_epoch - 1 because that row's scheduled_for falls
-- exactly at the current epoch boundary and is about to be processed.
-- Deleting epoch < v_epoch would remove rows that are due RIGHT NOW
-- (epoch E's row has scheduled_for = (E+1)*interval = now), causing
-- all notifications to stop firing — which is the bug this replaces.
DELETE FROM public.scheduled_notifications
WHERE announcement_id = ann.id
AND notify_type = 'announcement_banner'
AND processed = false
AND epoch < v_epoch - 1;
FOR usr IN
SELECT p.id
FROM public.profiles p
WHERE p.role::text = ANY(ann.visible_roles)
AND p.id <> ann.author_id
LOOP
-- scheduled_for = start of the NEXT epoch window (not now()).
-- This guarantees the row only becomes eligible AFTER the current
-- epoch ends, so a concurrent or delayed edge-function instance can
-- never see two different epochs' rows as simultaneously due.
INSERT INTO public.scheduled_notifications
(announcement_id, user_id, notify_type, scheduled_for, epoch)
VALUES
(ann.id, usr.id, 'announcement_banner',
to_timestamp(((v_epoch + 1)::bigint * ann.push_interval_minutes * 60)),
v_epoch)
ON CONFLICT DO NOTHING;
END LOOP;
END LOOP;
END;
$$;