Create Supabase schema for notification records
epic-certificate-expiry-notifications-data-foundation-task-002 — Design and apply the Supabase database migration that creates the notification_records table for persistent in-app notification state. Include columns for id, recipient_id, notification_type, threshold_days, title, body, is_read, created_at, and reference_id. Add indexes to support efficient queries by recipient and read status. Ensure the schema supports the 60/30/7-day threshold deduplication logic.
Acceptance Criteria
Technical Requirements
Implementation Notes
The unique constraint on (recipient_id, notification_type, threshold_days, reference_id) is the database-level deduplication guard — it complements the application-layer check in NotificationRecordRepository and protects against concurrent edge function invocations. Make threshold_days nullable so the table can store non-expiry notification types in the future without requiring a sentinel value. The RLS UPDATE policy should use a WITH CHECK clause: `WITH CHECK (is_read = true)` to ensure peers can only mark as read, never revert to unread or modify other fields. Consider adding a partial index on (recipient_id) WHERE is_read = false for maximum badge-count performance since unread rows are a small fraction of total rows.
Testing Requirements
Write SQL test scripts that: (1) insert a notification record and verify default values for is_read and created_at; (2) attempt to insert a duplicate (same recipient_id, notification_type, threshold_days, reference_id) and confirm the unique constraint rejects it; (3) run EXPLAIN ANALYZE on unread count and inbox listing queries to confirm index usage; (4) verify RLS: a peer mentor cannot read another recipient's notifications; (5) verify RLS UPDATE: a peer mentor cannot change the `body` column (should be rejected by a column-level restriction or trigger); (6) apply rollback and confirm clean drop. Commit SQL test scripts alongside the migration.
The RLS policy predicate that checks certification_expiry_date and suppression_status on every coordinator list query could cause full table scans at scale, degrading response time for coordinator contact list screens across all chapters.
Mitigation & Contingency
Mitigation: Add a partial index on (certification_expiry_date, suppression_status) filtered to active mentors. Benchmark the policy predicate against a representative data set (500+ mentors) during development using EXPLAIN ANALYZE on Supabase staging.
Contingency: If the index does not resolve the performance issue, introduce a computed boolean column is_publicly_visible that is updated by the mentor_visibility_suppressor service and indexed separately, shifting the predicate cost to write time rather than read time.
FCM device tokens become invalid when users reinstall the app or switch devices. If the token management strategy does not handle token refresh reliably, notification delivery will silently fail for a significant portion of the user base without surfacing errors.
Mitigation & Contingency
Mitigation: Implement the FCM token refresh callback in the Flutter client to upsert the latest token to Supabase on every app launch. Store token with a last_refreshed_at timestamp. The FCM sender should handle UNREGISTERED error codes by deleting stale tokens.
Contingency: If token staleness becomes widespread, add a token health check that forces re-registration during the expiry check edge function run by querying mentors whose token was last refreshed more than 30 days ago and triggering a silent push to prompt re-registration.
The certification expiry and notification record tables may have column naming or constraint conflicts with existing tables in the peer mentor status and certification management features, causing migration failures in shared Supabase environments.
Mitigation & Contingency
Mitigation: Audit existing table schemas for user_roles, certifications, and notification tables before writing migrations. Prefix new columns with expiry_ to avoid collisions. Run migrations against a clean Supabase branch environment before merging.
Contingency: If a conflict is found post-merge, apply ALTER TABLE migrations to rename conflicting columns and issue a hotfix migration. Communicate schema changes to all dependent feature teams via a shared migration changelog.