Integration test: full proxy registration pipeline
epic-bulk-and-proxy-registration-services-task-014 — Write integration tests against a Supabase test project that exercise the full pipeline: ProxyDuplicateDetector query → ProxyRegistrationService permission check → payload construction → ProxyActivityRepository persistence. Verify that the stored record has correct recorded_by_user_id and peer_mentor_id, that coordinator audit queries return only the coordinator's own records, and that peer mentor statistics queries aggregate by peer_mentor_id regardless of recorder. Include a NHF-style multi-coordinator duplicate scenario.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
Integration test setup is the hardest part of this task. Plan for: (1) a test fixtures file (test/integration/fixtures.dart) with factory functions for creating test users and scope assignments in Supabase; (2) a TestSupabaseClient wrapper that automatically uses the test project URL/key from environment; (3) a cleanup utility that uses the service role key to hard-delete all test data by a test run ID tag. For the NHF multi-coordinator scenario, create two coordinator users in the test project assigned to the same chapter, create a scope entry linking coordinatorB to mentorX, then have coordinatorA create an activity — then have coordinatorB attempt the same. The key assertion is that warning.originalRecordedByCoordinatorId returns coordinatorA's UUID.
For the statistics aggregation test, use a raw Supabase RPC call or a SELECT with GROUP BY peer_mentor_id to simulate how the app's stats screen would query — verifying the data model supports this query pattern is the core value of this test.
Testing Requirements
Use flutter_test with the real supabase_flutter client pointed at a dedicated test Supabase project. Integration test file should be in test/integration/ directory separate from unit tests. Use setUpAll() to create test users (coordinatorA, coordinatorB, mentorX, mentorY) and their scope assignments. Use addTearDown(cleanupFn) for each test to ensure cleanup runs even on failure.
For the RLS audit query test, sign in as coordinatorA and verify that a Supabase SELECT on the activities table with no additional filters only returns records where recorded_by_user_id == coordinatorA_id (RLS enforces this). For the peer mentor statistics test, insert two records for mentorX with different coordinators and verify the aggregate count is 2. Run integration tests in CI with a dedicated test Supabase project credential set.
The Proxy Registration Service must verify that the coordinator has a legitimate assignment relationship with the target peer mentor before creating a record. If this check is implemented only in application code and not enforced at the DB/RLS level, a compromised or buggy client could bypass it by calling the Supabase endpoint directly, creating fraudulent proxy records for arbitrary peer mentors.
Mitigation & Contingency
Mitigation: Implement permission validation at two levels: (1) application-layer check in Proxy Registration Service that queries the assignments table before constructing the payload, and (2) RLS policy on the activities table that restricts INSERT to rows where recorded_by_user_id matches the authenticated user AND peer_mentor_id is in the set of peer mentors assigned to that coordinator. The RLS policy is the authoritative guard; the service-layer check provides early user-facing feedback.
Contingency: If RLS policy implementation is blocked by Supabase plan constraints, implement a Supabase Edge Function as a proxy endpoint that enforces the permission check server-side before forwarding to the DB. Disable direct client inserts entirely for proxy activities.
For a bulk session with 30 selected peer mentors, the Proxy Duplicate Detector must query existing activities for each mentor. If implemented as 30 sequential Supabase queries, round-trip latency could make the bulk confirmation screen feel slow (>3s), degrading coordinator experience and potentially causing timeouts.
Mitigation & Contingency
Mitigation: Implement the duplicate check as a single Supabase query using an IN clause on peer_mentor_id combined with the activity_type and date filters, returning all potential duplicates for the entire batch in one network round-trip. Group results client-side by mentor ID to produce the per-mentor warning structure.
Contingency: If the single-query approach returns too much data for very large chapters, add a database index on (peer_mentor_id, activity_type, date) and profile query time. If still insufficient, accept a short loading state on the confirmation screen with a progress indicator rather than pre-loading duplicates before navigation.