Integration test: expiry checker end-to-end flow
epic-peer-mentor-pause-management-automated-expiry-task-010 — Write integration tests covering the full CertificationExpiryChecker pipeline: seed test mentors with certifications at 30d, 14d, 7d, and 0d thresholds; run the checker; assert correct status transitions, correct reminder notifications dispatched at each threshold, idempotency on repeated runs, and accurate audit log entries. Tests must run against a Supabase test instance.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Implementation Notes
The most critical design decision for these tests is clock injection — CertificationExpiryChecker must accept a configurable 'reference date' (via an env var or function input parameter) so tests can simulate arbitrary dates without waiting or manipulating system time. This should be designed in during implementation of the checker itself (task-005). For seeding, write a Dart helper class TestCertificationSeeder with typed seed methods (seedMentorExpiringInDays(int days)) to keep test bodies readable. Run tests against a dedicated Supabase test project provisioned in CI — use Supabase CLI (supabase start) or a pre-provisioned test project.
Mock FCM by intercepting the Edge Function's outbound HTTP call with a WireMock container or by injecting a stub notification service. Assert notification dispatch by querying a notifications_log table that the checker writes to, rather than verifying actual FCM delivery.
Testing Requirements
Integration tests using flutter_test and direct Supabase client calls. Structure: setUp() seeds all test mentors and certifications with clock-mocked expiry dates; test() invokes CertificationExpiryChecker Edge Function via HTTP; assertions query Supabase database for resulting status values, notification_log rows, and audit_log rows. Use a date injection mechanism (environment variable or function parameter) to control 'today' in the checker without system clock manipulation. Teardown drops all seeded rows after each test.
Include negative tests: certification expiring in 31 days (no notification expected), mentor with no certification (no error expected).
The nightly expiry checker may run multiple times due to scheduler retries or infrastructure issues, causing duplicate auto-transitions and duplicate coordinator notifications that erode trust in the notification system.
Mitigation & Contingency
Mitigation: Implement idempotency via a unique constraint on (mentor_id, threshold_day, certification_expiry_date) in the cert_expiry_reminders table. Auto-transitions should be wrapped in a Postgres RPC that checks current status before applying, making repeated invocations safe.
Contingency: Add a compensation query in the reconciliation log that detects duplicate log entries for the same certification period and alerts the operations team for manual review within 24 hours.
The HLF Dynamics portal API may have eventual-consistency behaviour or rate limits that cause website listing updates to lag behind status changes, leaving expired mentors visible on the public website for an unacceptable window.
Mitigation & Contingency
Mitigation: Design the sync service to be triggered immediately on status transitions (event-driven via database webhook) in addition to the nightly batch run. Implement a reconciliation job that verifies sync state against app state and re-triggers any divergent records.
Contingency: If real-time sync cannot be guaranteed, implement a manual 'force sync' action in the coordinator dashboard so coordinators can trigger an immediate re-sync for urgent cases. Document the expected sync lag in coordinator onboarding materials.
Stakeholder requests to extend the expiry checker to handle additional certification types, grace periods, or organisation-specific threshold configurations may significantly increase scope beyond what is designed here, delaying delivery.
Mitigation & Contingency
Mitigation: Parameterise threshold day values (30, 14, 7) via configuration repository rather than hard-coding them, enabling per-organisation customisation without code changes. Document that grace period logic and additional cert types are out of scope for this epic and require a dedicated follow-up.
Contingency: Deliver the feature with hard-coded HLF-standard thresholds first and introduce the configuration repository as a follow-up task in the next sprint, using a feature flag to enable per-org threshold overrides.
Dynamics portal API credentials stored as environment secrets in Supabase Edge Function configuration may be rotated or invalidated by HLF IT without notice, causing silent sync failures that go undetected for multiple days.
Mitigation & Contingency
Mitigation: Implement credential health-check calls on each scheduler run and emit an immediate alert on auth failure rather than only alerting after N consecutive failures. Document the credential rotation procedure with HLF IT and establish a rotation notification protocol.
Contingency: Maintain a break-glass manual sync script accessible to HLF administrators that can re-execute the Dynamics sync with newly provided credentials while the automated system is restored.