critical priority low complexity deployment pending devops specialist Tier 8

Acceptance Criteria

Webhook Edge Function is deployed and reachable at its Supabase project URL with a 200 response on a valid HMAC-signed POST
Database webhook trigger is configured on peer_mentor_profiles.status column for both INSERT and UPDATE events
HMAC secret is stored as a Supabase project secret (not hardcoded) and validated on every incoming request
Retry policy is configured with at least 3 attempts and exponential backoff (1s, 5s, 30s)
End-to-end staging test: updating status to 'paused' triggers webhook, FCM notification is received by coordinator within 5 seconds
End-to-end staging test: updating status to 'active' (resume) triggers webhook, coordinator receives resume notification within 5 seconds
Webhook rejects requests with invalid or missing HMAC signature with HTTP 401
Webhook returns HTTP 200 promptly to prevent Supabase retry on successful delivery
Deployment is documented with rollback instructions
No sensitive secrets appear in Edge Function logs or error output

Technical Requirements

frameworks
Supabase Edge Functions (Deno)
Supabase CLI
apis
Supabase Database Webhooks API
Supabase Secrets API
FCM HTTP v1 API
data models
PauseStatusRecord
peer_mentor_profiles
performance requirements
Coordinator notification delivered within 5 seconds of status column change
Edge Function cold-start must not exceed 2 seconds
Webhook handler must respond with HTTP 200 within 3 seconds to avoid Supabase retry
security requirements
HMAC-SHA256 signature validation on all incoming webhook requests
HMAC secret stored exclusively in Supabase project secrets, never in source code
Edge Function must not log PII (mentor name, coordinator contact details)
Webhook endpoint must reject replay attacks (validate timestamp within 5-minute window)

Execution Context

Execution Tier
Tier 8

Tier 8 - 48 tasks

Can start after Tier 7 completes

Implementation Notes

Use `supabase functions deploy pause-status-webhook` via Supabase CLI. Configure the database webhook in the Supabase Dashboard under Database → Webhooks, pointing to the deployed Edge Function URL with the HMAC secret header. Store the HMAC secret with `supabase secrets set WEBHOOK_HMAC_SECRET=`. In the Edge Function, validate the `x-supabase-signature` header using the crypto API available in Deno.

Return HTTP 200 immediately after successful FCM dispatch — do not await coordinator delivery confirmation. For the 5-second SLA, the critical path is: DB trigger fires → Edge Function invoked → FCM HTTP v1 API call completes → device receives push. Profile each hop in staging to identify any bottleneck. Ensure the trigger is scoped only to the `status` column change (use `WHEN (OLD.status IS DISTINCT FROM NEW.status)`) to avoid spurious webhook calls on unrelated updates.

Testing Requirements

Integration tests in staging environment: (1) Trigger status UPDATE to 'paused' via direct Supabase client call, assert FCM notification received by coordinator within 5s. (2) Trigger status UPDATE to 'active' (resume), assert coordinator resume notification received. (3) Send POST with invalid HMAC signature, assert HTTP 401 returned and no notification dispatched. (4) Simulate webhook retry by returning non-200 on first attempt, assert retry fires and notification eventually delivered.

(5) Confirm Edge Function logs contain no PII. All tests run against the staging Supabase project before any production deployment.

Component
Pause Status Webhook Handler
infrastructure low
Epic Risks (3)
medium impact medium prob technical

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.

medium impact medium prob technical

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.

medium impact low prob scope

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.