Integration test: ContactEditService partial update and ReadReceiptService audit write
epic-contact-detail-and-edit-service-layer-task-014 — Write integration tests covering ContactEditService diff computation (only changed fields submitted), user-readable error surfacing, and ContactDetailService refresh after save. Include tests for ReadReceiptService: receipt row written with correct field key and user ID, confirmation state emission, and retry behaviour on network failure to satisfy compliance audit requirements.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
The diff computation logic is the most critical correctness concern — test it exhaustively with matrix-style cases: (a) one field changed, (b) multiple fields changed, (c) no fields changed, (d) field changed back to original value (should be treated as unchanged). For the Supabase fake, capture the last payload passed to the update method in a recorded variable so test assertions can inspect it directly. For ReadReceiptService retry tests, inject a configurable max-retry count so tests can use maxRetries=2 instead of production defaults — this keeps tests fast. The compliance audit requirement means ReadReceiptFailed state must never be silently swallowed: add an assertion that the error is also logged to a structured logger mock (if one exists in the app), not just emitted as a state.
After save, verify the refresh sequence is: save completes → receipt written → detail refreshed — if order matters for UX, assert it explicitly with sequential state inspection.
Testing Requirements
Integration tests covering ContactEditService and ReadReceiptService as a pair. Group tests into three sections: (1) diff computation and partial update correctness, (2) error surfacing and refresh orchestration, (3) ReadReceiptService audit write with retry and failure states. Use FakeAsync for all retry timing. Use call-count assertions on Supabase fake to verify partial update payload.
Use StreamQueue to assert ordered state emissions. Compliance requirement: ReadReceiptService tests must explicitly assert that the user ID field is present in the written row — add a comment referencing the Bufdir compliance audit requirement so future maintainers understand the purpose.
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.