🏠 Overview › ✅ Implementation Tasks ›✅ epic-pause-status-notifications-ui-task-007

Trigger banner on pause state change events

epic-pause-status-notifications-ui-task-007 — Integrate PeerMentorConfirmationBanner with the notification trigger pipeline so it surfaces whenever the peer mentor receives a pause-activated or pause-deactivated in-app event. Listen to the relevant BLoC or Riverpod state and call the banner display utility with the appropriate payload. Ensure the banner is shown on both pause activation and deactivation paths.

high priority low complexity integration pending integration specialist Tier 2

Acceptance Criteria

When the BLoC or Riverpod provider emits a `pauseActivated` state transition, PeerMentorConfirmationBanner is rendered in the UI with the `pauseActivated` event type and the correct effective date
When the BLoC or Riverpod provider emits a `pauseDeactivated` state transition, PeerMentorConfirmationBanner is rendered with `pauseDeactivated` and the correct effective date
Banner is shown only once per state change event — rapid duplicate events do not stack multiple banners
Banner triggers correctly whether the state change originates from a Supabase Realtime websocket event or from an FCM push notification
After the banner auto-dismisses or is manually closed, the state is updated so the banner does not reappear on hot-restart or screen re-entry
Banner trigger logic does not fire for peer mentors who are not the currently authenticated user
No banner is shown if the app is in the background; on foreground restore, banner triggers only if the event occurred while the app was foregrounded
Integration does not introduce a new global listener pattern — it reuses the existing notification event pipeline

Technical Requirements

frameworks
Flutter
BLoC
Riverpod
Supabase Realtime (websocket)
apis
Supabase Realtime pause-status channel
Firebase Cloud Messaging (FCM) API v1
data models
assignment
performance requirements
State listener callback executes synchronously within the UI event loop — no artificial delays
Banner display does not trigger a full widget tree rebuild beyond its insertion point
security requirements
Pause event payload validated before constructing the banner model — malformed payloads are discarded with a debug log
RLS on Supabase Realtime ensures only the authenticated peer mentor receives their own pause-status events
JWT validated on every Realtime channel subscription
ui components
PeerMentorConfirmationBanner (task-006)
BLoC listener or Riverpod consumer wrapper

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Use a `BlocListener` (if BLoC) or `ref.listen` (if Riverpod) to react to state changes — do not use `StreamBuilder` directly on Supabase Realtime inside the widget. Introduce a `bannerShown` flag in the BLoC/provider state to prevent duplicate display. The banner model should be constructed at the state-emission point (in the BLoC event handler or Riverpod notifier), not inside the widget tree. For FCM-originated events, convert the FCM payload to the same internal event format used by Realtime before passing to the state manager — single processing path, two entry points.

Ensure the Supabase Realtime subscription filters by the authenticated user's mentor ID via the channel filter parameter.

Testing Requirements

Integration test: mock the BLoC/provider to emit a `pauseActivated` event and assert the banner appears in the widget tree; emit `pauseDeactivated` and assert the correct banner variant appears; emit two rapid `pauseActivated` events and assert only one banner instance exists in the tree; simulate banner dismissal and emit the same event again — assert no second banner appears until a new event. Unit test the trigger logic in isolation from the widget. Verify Realtime channel subscription is cleaned up when the listening widget is disposed.

Component
Peer Mentor Confirmation Banner
ui low
Dependencies (1)
Build the Flutter inline toast/banner widget shown to peer mentors on pause activation and deactivation. Display a confirmation message that references the event type (paused or resumed) and the effective date. Apply the existing toast/banner pattern and design tokens so the component is visually consistent with other app banners. Implement auto-dismiss after a configurable short delay (default 4 seconds). epic-pause-status-notifications-ui-task-006
Epic Risks (2)
medium impact low prob integration

The existing notification feed component may expect a specific notification model shape that does not map cleanly to the pause notification payload structure, requiring either payload transformation or feed refactoring.

Mitigation & Contingency

Mitigation: Review the notification-list-item and notification-model contracts before building the card. Design the pause-notification-card to extend or wrap the existing list item pattern rather than replacing it.

Contingency: If the feed contract is incompatible, implement a lightweight adapter that maps the pause notification payload to the feed's expected model shape, keeping the adapter isolated from the core card widget.

low impact low prob dependency

The app's existing toast/banner infrastructure may not support the auto-dismiss timeout duration or dismissal animation required for the peer mentor confirmation banner, necessitating a custom implementation that diverges from the design system.

Mitigation & Contingency

Mitigation: Audit the existing banner and toast components (in-app-notification-banner, notification-list-item) for configurable dismiss timeout before starting implementation. Prefer configuration over custom code.

Contingency: If the existing infrastructure cannot be configured, implement the banner as a thin wrapper with a custom auto-dismiss timer while reusing all visual tokens (colours, spacing, typography) from the design system to maintain consistency.

Quick Links
All Tasks Execution Plan