Emit typed BLoC events from ProxyRegistrationService
epic-proxy-activity-registration-orchestration-task-005 — Implement the typed event emission layer in ProxyRegistrationService so that on success it emits ProxyRegistrationSucceeded, on duplicate conflict it emits ProxyRegistrationDuplicateDetected, and on repository or authorization error it emits ProxyRegistrationFailed. The events must carry sufficient payload for the BLoC to build the correct UI state without additional data fetching.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 10 - 11 tasks
Can start after Tier 9 completes
Implementation Notes
Define ProxyRegistrationEvent as a sealed class hierarchy (Dart 3 sealed or freezed). The service should return a ProxyRegistrationResult (also sealed), and the BLoC translates the result into the corresponding event using a switch expression. Keep the emission logic as a thin translation layer — no business logic should live here. This separation means the service is independently testable without a BLoC, and the BLoC is testable with a mocked service.
Use the bloc_test package's emitsInOrder matcher to assert exact event sequences. Ensure error messages are localized and do not contain raw Supabase error strings — define a ProxyRegistrationErrorCode enum with values like duplicateConflict, networkFailure, authorizationDenied, unknown, and map error codes to user-facing strings in the UI layer.
Testing Requirements
Write BLoC unit tests using flutter_test and bloc_test package. Test scenarios: (1) service returns success → BLoC emits ProxyRegistrationSucceeded with correct activity ID; (2) service returns duplicate conflict → BLoC emits ProxyRegistrationDuplicateDetected with full conflict reference; (3) service returns error → BLoC emits ProxyRegistrationFailed with typed error code; (4) no event is emitted twice for a single registration call; (5) BLoC state after each event matches expected UI state variant. Confirm compile-time exhaustiveness by ensuring the sealed event hierarchy has no unhandled cases in the BLoC switch.
If the Supabase batch RPC partial-inserts some records before encountering an error and does not roll back cleanly, the bulk service may report failure while orphaned records exist in the database, corrupting reporting data.
Mitigation & Contingency
Mitigation: Wrap the bulk insert in an explicit Supabase transaction via the RPC function. Write an integration test that simulates a mid-batch constraint violation and asserts zero records were written.
Contingency: If a partial-write incident occurs, the registered_by audit field allows identification and deletion of the orphaned records. Implement a coordinator-facing bulk submission status screen to surface any such anomalies.
When a bulk submission of 15 participants has 4 duplicates, the aggregated conflict summary may be too complex for coordinators to process quickly, leading to blanket override decisions that defeat the purpose of duplicate detection.
Mitigation & Contingency
Mitigation: Design the conflict result type to support per-participant override flags, so the UI can present a clear list of conflicting participants with individual cancel/override toggles rather than a single global decision.
Contingency: If coordinator usability testing reveals the conflict review screen is too complex, simplify to a 'skip all conflicts and submit the rest' mode as an immediate fallback while a more granular UI is designed.
If the coordinator role check inside proxy-registration-service is inconsistent with the route-level guard, a regression in the guard could allow peer mentors to call the service directly via deep links, submitting records with incorrect attribution.
Mitigation & Contingency
Mitigation: Enforce role authorization at both the route guard level (coordinator-role-guard) and inside each service method independently. Write a security test that calls the service directly with a peer mentor session token and asserts rejection.
Contingency: If a bypass is discovered, immediately enable the server-side RLS policy as the final enforcement layer and audit any records written during the exposure window using the registered_by field.