Unit tests for InAppNotificationRepository
epic-assignment-follow-up-reminders-foundation-task-009 — Write unit tests for InAppNotificationRepository covering: insert a notification record, mark as read, fetch unread for user scoped to org, fetch by assignment, delete old records, and RLS enforcement for cross-org access. Use flutter_test with Supabase mock. Verify correct SQL filter parameters are passed in each query.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
The dual-filter requirement on markAsRead (notificationId AND userId) is a deliberate security control — ensure the repository implementation uses .eq('id', notificationId).eq('user_id', userId) in the update chain, and the test verifies both filters are present. The deleteOldRecords method likely uses .lt('created_at', olderThan.toIso8601String()) — the test should pass a known DateTime and assert the exact ISO string. For the cross-org RLS test: Supabase RLS silently returns empty sets (no 403), so the expected behavior is an empty list, not an exception. This is different from the ReminderConfigRepository where an empty result for fetchConfig is unexpected and should throw.
Testing Requirements
Unit tests only. Pay particular attention to the markAsRead dual-filter test — this is a security-relevant assertion (IDOR prevention). Use argument captors (mocktail's any() + verify()) to assert the exact Map passed to the Supabase update/insert calls, not just that the method was called. For the deleteOldRecords test, freeze time using a fixed DateTime in the test to make the lt filter assertion deterministic.
Group tests logically using group() blocks: 'insert operations', 'read operations', 'update operations', 'delete operations', 'RLS scoping'.
Adding last_contact_date to the assignments table may conflict with existing RLS policies or trigger-based logic that monitors the assignments table. If the migration is not carefully reviewed, existing assignment management features could break in production.
Mitigation & Contingency
Mitigation: Review all existing triggers, policies, and foreign key constraints on the assignments table before writing the migration. Run the migration against a staging Supabase instance with production-like data and execute the full existing test suite before merging.
Contingency: Roll back the migration using Supabase's versioned migration history. Apply the schema change as an additive-only migration (nullable column with default) to ensure zero downtime and reversibility.
The PushNotificationService wraps an existing FCM integration whose internal API contract may have changed or may not expose the payload formatting required for deep-link CTAs. Misalignment discovered late delays the dispatch service epic.
Mitigation & Contingency
Mitigation: Before implementing the wrapper, read the existing push notification integration code and confirm the method signatures, payload structure, and token management model. Agree on a stable interface contract in a shared Dart abstract class.
Contingency: If the existing service is incompatible, implement a thin adapter layer that translates reminder payloads to the existing service's format, isolating the reminder feature from upstream changes.
Incorrect RLS policies on notification_log could allow coordinators to read reminder records belonging to peer mentors in other chapters, exposing sensitive assignment information across organisational boundaries.
Mitigation & Contingency
Mitigation: Write explicit RLS policies with integration tests that assert cross-chapter queries return zero rows. Use Supabase's built-in auth.uid() and join through the org membership tables to scope all queries.
Contingency: If a policy gap is discovered post-merge, immediately disable the affected table's SELECT policy, deploy a corrected policy, and audit recent queries in Supabase logs for any cross-boundary reads.