Web error log showed:
update or delete on table "whatsapp_groups" violates foreign key
constraint "reminder_targets_group_id_whatsapp_groups_id_fk" on
table "reminder_targets"
Repro: pair finishes, post-open syncGroupsForAccount runs and tries
to DELETE rows for groups no longer in the live participant list.
If any of those groups had been used in a reminder its row is FK-
referenced from reminder_targets, so the DELETE aborts the whole
transaction and the operator's pair completion appears to fail.
With 3 000+ groups per account this hits anyone with even a small
reminder history.
Switch the sweep from DELETE to UPDATE … SET is_archived=true.
Reminders that targeted the missing group keep working (operator
can choose to remove them); a future re-pair where the group
reappears flips is_archived back to false via the on-conflict
upsert. Returns archived count instead of removed count.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously syncGroupsForAccount only upserted, so groups removed from
WhatsApp (deleted, bot was kicked, etc.) lingered in the DB.
Now compute the diff: any whatsapp_groups row for this account whose
wa_group_jid is not in the live fetch result is deleted. Skip the delete
sweep when the fetch returns empty — that's more likely transient than
a genuine "every group gone" signal, and we don't want to nuke valid
data on a hiccup.
Return shape gains a `removed` count alongside `synced`.
