Confirm the bounce alert link migration is applied on production #354

Parent

#328. Related: #249

What to build

When an email to a person bounces, docs.plus pauses their email and adds a bell alert. Before migration 20260922120000, that alert linked to /settings/notifications. The webapp has no such route, so a click opened a pad named "settings". The migration points the link at /#settings?tab=notifications, which opens Settings. On 2026-09-28 the production migration history did not list this version. This issue confirms it is applied, and applies it if not.

Acceptance criteria

• bunx supabase migration list --linked shows 20260922120000 in the Remote column.
• On production, the body of public.record_email_bounce contains '/#settings?tab=notifications'.
• No other pending migration was applied as a side effect of this issue.
• The result is posted as a comment on this issue: already applied, or applied on a given date.

Blocked by

None — can start now.

Agent brief

Type: HITL — only the maintainer has production database access. The maintainer runs the checks, applies the file if needed, and posts the result here.

Category: bug

Current behavior: packages/supabase/migrations/20260922120000_system_alert_settings_hash_link.sql replaces one function, public.record_email_bounce. Only the action_url of the system_alert insert changes. The paired script is packages/supabase/scripts/07-5-email-notifications-pgmq.sql. A read-only check on 2026-09-28 found the production history ended at 20260921120000 (unverified from the repo; step 1 checks it again). Later migrations may also be pending on production.

Desired behavior: Production runs the new function body, and its history row for 20260922120000 exists.

Where to start: The migration file above. packages/supabase/CLAUDE.md §Supabase, the bullets on remote db push and on history divergence.

Line numbers are hints as of 2026-09-28; the agent searches by symbol.

Rules that apply: packages/supabase/CLAUDE.md §Supabase:

• bunx supabase migration list is the ground truth. Run it before any repair.
• migration repair --status applied only edits history. Use it only after the SQL has run.
• db push pushes every pending migration, not one. So check the list first.
• [db.migrations] enabled goes true only while pushing, then back to false. Never leave it true in a commit.

Steps:

1. From packages/supabase, link the CLI to the production project if it is not linked yet: bunx supabase link --project-ref <production ref>. The link lives in the gitignored .temp/ folder. Then run bunx supabase migration list --linked. If 20260922120000 has a Remote value, go to step 4.
2. If 20260922120000 is the only pending version, push it with bunx supabase db push --linked, with [db.migrations] enabled set to true for that run only.
3. If other versions are pending too, do not use db push. Run the file's SQL in the Supabase SQL editor. Then run bunx supabase migration repair --status applied 20260922120000 --linked. The other pending versions stay for their own owners.
4. Run the check query below in the Supabase SQL editor and confirm the new link.

select position('/#settings?tab=notifications' in pg_get_functiondef('public.record_email_bounce(text,text,text,text)'::regprocedure)) > 0 as has_hash_link;

Verify: The check query returns true. bunx supabase migration list --linked shows 20260922120000 on both sides. git diff packages/supabase/config.toml is empty after the run. No type regeneration is needed, because the function signature is unchanged.

Out of scope

• Any other pending migration. Each has its own owner and review.
• Editing the migration file. An applied or committed migration is never edited.
• The bounce alert device check, which Run the PWA device checklist and close each #249 child that passes #355 runs after this issue.