Write unit and integration tests for pipeline
epic-pause-status-notifications-backend-pipeline-task-011 — Write unit tests for payload validation, transition detection, coordinator resolution, and payload building. Write integration tests that simulate Supabase webhook events end-to-end through the Edge Function to FCM dispatcher and in-app store, covering both pause and resume transitions. Verify the 5-second SLA under simulated load and confirm no silent failures occur for missing coordinator scenarios.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 7 - 84 tasks
Can start after Tier 6 completes
Implementation Notes
Start by writing the integration test fixtures (SQL seed scripts) for the three key scenarios: (1) mentor with coordinator and FCM tokens for both, (2) mentor with no coordinator assignment, (3) mentor with stale FCM token. These fixtures drive the integration tests and also serve as documentation of expected database state. For unit tests, the pure function architecture (tasks 006-009 all recommend stateless functions) means most units can be tested without any mocking — just call with typed inputs and assert typed outputs. The only mocking needed is for the Supabase client (in resolver and dispatcher) and the FCM HTTP client.
For the SLA test, use `performance.now()` around the full orchestrator.run() call with mocked dependencies that introduce 800ms artificial delays to simulate realistic FCM latency. Document test execution instructions in a README.md in the Edge Function directory.
Testing Requirements
Test architecture: unit tests using Deno's built-in mock/stub utilities (std/testing/mock) for all external dependencies. Integration tests using a test Supabase project with seeded data via SQL fixture scripts. FCM calls intercepted with a local mock HTTP server (e.g., Deno's std/http/server in test setup). Coverage measured via `deno test --coverage` and reported as lcov.
CI integration: tests run on every PR via GitHub Actions with Deno setup action. Test file naming: `*.test.ts` co-located with source files. Required test files: `payload-validator.test.ts`, `transition-detector.test.ts`, `coordinator-resolver.test.ts`, `payload-builder.test.ts`, `fcm-dispatcher.test.ts`, `in-app-dispatcher.test.ts`, `orchestrator.integration.test.ts`, `webhook-handler.integration.test.ts`.
Supabase Edge Functions have cold start latency that may push coordinator notification delivery beyond the 5-second SLA, particularly during low-traffic periods when the function is not warm.
Mitigation & Contingency
Mitigation: Keep the Edge Function lightweight — delegate all heavy logic to the orchestrator layer and avoid large dependency bundles. Measure p95 end-to-end latency in staging and document actual SLA achievable.
Contingency: If cold start latency consistently breaches 5 seconds, introduce a keep-warm ping from the nightly-scheduler or document the actual p95 latency in the feature spec and adjust the acceptance criterion to reflect the realistic bound.
Supabase database webhooks may fire duplicate events for a single status change under retry conditions, causing coordinators to receive multiple identical notifications for one pause event.
Mitigation & Contingency
Mitigation: Add idempotency checking in the webhook handler using the event timestamp and peer mentor ID. Store a notification dispatch record in the pause-status-record-repository and skip dispatch if a record for the same event already exists.
Contingency: If duplicates slip through in production, add a de-duplication filter in the notification centre UI layer so the coordinator sees at most one card per event, and implement a cleanup job for the notifications table.
A peer mentor with multi-chapter membership may have more than one responsible coordinator. The orchestrator design currently targets a single coordinator, and resolving multiple recipients may require schema changes to the org membership query.
Mitigation & Contingency
Mitigation: Review the multi-chapter-membership-service patterns before implementing the orchestrator's coordinator resolution. Design the dispatcher call to accept an array of coordinator IDs from the outset so adding multiple recipients is non-breaking.
Contingency: If multi-coordinator dispatch is out of scope for this epic, document the limitation and create a follow-up task. Default to the primary coordinator (lowest chapter hierarchy level) as the single recipient in the interim.