Implement Proxy Registration BLoC (Unified State)
epic-coordinator-proxy-registration-bulk-orchestration-task-012 — Build the ProxyRegistrationBLoC using the flutter_bloc library to provide unified state management for both single and bulk proxy registration flows. Manage loading states, form validation feedback, mentor selection state, template pre-fill events, and submission result states including partial failure scenarios. Expose streams consumed by both ProxyRegistrationScreen and BulkProxyRegistrationScreen. Ensure that bulk submission progress updates are streamed per-mentor so the UI can show granular feedback. Write unit tests covering all state transitions including partial failure paths.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
Wire the BulkRegistrationOrchestrator's progress Stream into the BLoC by adding a subscription inside the event handler: await emit.forEach(progressStream, onData: (update) => BulkRegistrationProgress(...)). This is the canonical flutter_bloc pattern for streaming side effects. Use on
Keep the BLoC thin — all business logic lives in ProxyRegistrationService and BulkRegistrationOrchestrator; the BLoC only coordinates events and maps results to UI states.
Testing Requirements
Use bloc_test's blocTest
Partial failures in bulk registration — where some mentors succeed and others fail — create a complex UX state that is easy to mishandle. If the UI does not clearly communicate which records succeeded and which failed, coordinators may re-submit already-saved records (creating duplicates) or miss failed records entirely (creating underreporting).
Mitigation & Contingency
Mitigation: Design the per-mentor result screen as a primary deliverable of this epic, not an afterthought. Use a clear list view with success/failure indicators per mentor name, and offer a 'Retry failed' action that pre-selects only the failed mentors for resubmission.
Contingency: If partial failure UX proves too complex to deliver within scope, implement a simpler all-or-nothing submission mode for the initial release with a clear error message listing which mentors failed, and defer the partial-retry UI to a follow-up sprint.
Submitting proxy records for a large group (e.g., 30+ mentors) as individual Supabase inserts may cause latency issues or hit rate limits, degrading the coordinator experience and potentially causing timeout failures that leave data in an inconsistent state.
Mitigation & Contingency
Mitigation: Implement the BulkRegistrationOrchestrator to batch inserts using a Supabase RPC call that accepts an array of proxy records, reducing round-trips to a single network call. Add progress indication using a stream of per-record results if the RPC supports it.
Contingency: If the RPC approach is blocked by Supabase limitations, fall back to chunked parallel inserts (5 records per batch) with retry logic, capping total submission time and surface a progress bar to manage coordinator expectations.
Unifying state management for both single and bulk proxy flows in a single BLoC risks state leakage between flows — for example, a previously selected mentor list persisting when a coordinator switches from bulk to single mode — causing confusing UI states or incorrect submissions.
Mitigation & Contingency
Mitigation: Define separate, named state subtrees within the BLoC for single-proxy state and bulk-proxy state, with explicit reset events triggered on flow entry. Write unit tests for state isolation scenarios using the bloc_test package.
Contingency: If unified BLoC state becomes unmanageable, split into two separate BLoCs (ProxySingleRegistrationBLoC and ProxyBulkRegistrationBLoC) sharing only common events via a parent coordinator Cubit.