Surface user-readable save errors from ContactEditService
epic-contact-detail-and-edit-service-layer-task-007 — Map repository and validation error codes returned during contact save operations to user-readable Norwegian error messages within ContactEditService. Emit ContactEditError states carrying the translated message string so the UI layer can display error banners without containing any error-message logic.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Create a private _mapErrorToUserMessage(Object error) method inside ContactEditService (or a co-located ContactEditErrorMapper class if reuse is anticipated). Use a switch/if-else chain on the error type and code property. For Supabase errors, cast to PostgrestException and switch on .code. For domain validation errors, switch on a custom ErrorCode enum defined in the repository layer.
Store all Norwegian strings as constants at the top of the mapper — never inline in switch branches — to make future translation or copy-edit easy. Ensure the BLoC/Riverpod notifier catches the error in a try/catch block, calls _mapErrorToUserMessage, and emits ContactEditError(userMessage: msg) instead of rethrowing. The state stream must remain open after emitting an error state so the user can retry.
Testing Requirements
Write pure unit tests in flutter_test covering: (1) each explicitly mapped Supabase error code produces the correct Norwegian string, (2) each validation error code maps correctly, (3) an unknown error code produces the generic fallback string, (4) ContactEditError.userMessage is never null or empty for any input. No widget or integration tests required for this task. Aim for 100% branch coverage of the mapping method.
Parallel fetching of profile, activity history, and assignment status from contact-detail-service may produce race conditions where partial state is emitted to the UI before all fetches complete, resulting in flickering or incorrect loading indicators.
Mitigation & Contingency
Mitigation: Use Future.wait or a single composed BLoC event that only emits a loaded state once all three futures resolve. Define a strict state machine: initial → loading → loaded/error with no intermediate partial-loaded states emitted to the UI.
Contingency: If parallelism proves unreliable in testing, fall back to sequential fetching with a combined loading indicator. The 500ms target may need to be renegotiated with stakeholders if sequential fetching exceeds it on slow connections.
The partial-field update pattern in contact-edit-service assumes the contact record has not changed between when the edit screen was loaded and when the save is submitted. Concurrent edits by another coordinator could cause the earlier editor's save to silently overwrite the later one.
Mitigation & Contingency
Mitigation: Include an updated_at timestamp in the PATCH request and configure Supabase to reject updates where the server-side timestamp differs from the client's version. Return a 409-equivalent error that the service maps to a user-readable conflict message.
Contingency: If optimistic locking is too complex for initial delivery, implement a simple 'reload and retry' flow: on save error, reload the contact detail and prompt the coordinator to re-apply their changes manually.