Build reactivation flow on PauseActivationScreen
epic-peer-mentor-pause-management-core-workflows-task-008 — Extend the PauseActivationScreen to handle the reactivation journey when the current mentor status is paused. Show a reactivation prompt with the original pause reason and expected return date displayed as context. Provide a reactivate action that calls PauseManagementService.reactivateMentor() and returns the mentor to active status. Use the PauseStatusIndicator widget to reflect the updated state after reactivation.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Implementation Notes
Extend the existing PauseManagementBloc by adding a ReactivationRequested event and PauseReactivationSuccess / PauseReactivationError states. In the UI, use BlocBuilder to conditionally render the pause flow or the reactivation flow based on the current assignment status in the BLoC state — avoid duplicating the screen into two separate widgets; a single screen with conditional rendering is cleaner and avoids navigation route complexity. After successful reactivation, emit a state that updates the PauseStatusIndicator in-place rather than popping the screen and relying on the parent to refresh. This prevents stale status display on the parent screen.
Testing Requirements
Write widget tests using flutter_test covering: (1) screen renders reactivation flow when BLoC state indicates paused status, (2) original pause reason and expected return date are displayed correctly, (3) reactivate button is disabled during loading, (4) success updates PauseStatusIndicator to active, (5) error renders accessible error message. Verify the conditional rendering logic with both paused and active initial states to ensure the correct flow is shown. Test null/empty pause reason displays the fallback string.
Concurrent status transitions (e.g., coordinator and automated scheduler both attempting to update the same mentor's status simultaneously) may produce race conditions or inconsistent state in the database, leading to audit log gaps or incorrect notifications.
Mitigation & Contingency
Mitigation: Implement all status transitions as atomic Postgres RPC functions with optimistic locking (version column or updated_at check). Use database-level constraints rather than application-level guards as the final enforcement point.
Contingency: Add a compensation job that reconciles status and log table consistency on each nightly scheduler run, surfacing any discrepancies to coordinator dashboards.
The coordinator-to-mentor assignment relationship may not always be 1:1 or may be stale (coordinator reassigned after a pause was set), causing notifications to be sent to the wrong coordinator or not sent at all.
Mitigation & Contingency
Mitigation: Query the assignment relationship at notification dispatch time rather than caching it at pause creation time. Add a fallback to notify the chapter administrator if no active coordinator assignment exists.
Contingency: Log all undeliverable notification attempts with the originating mentor ID so administrators can manually follow up, and surface undelivered notification counts on the coordinator dashboard.
The CoordinatorPauseRosterScreen may load slowly for coordinators managing large rosters with many concurrent certification expiry queries, degrading usability on low-bandwidth mobile connections.
Mitigation & Contingency
Mitigation: Use a single Supabase RPC that joins mentor status, certification expiry, and assignment data in one query rather than N+1 individual calls. Implement pagination with a configurable page size and skeleton loading states.
Contingency: Add an offline cache of the last-fetched roster state using Riverpod with SharedPreferences, ensuring coordinators can at minimum view stale data when connectivity is poor.