Notification Read State Service

The Notification Read State Service is a medium-complexity component whose primary delivery risk lies in the optimistic update and rollback logic. Simulating server failures in automated tests requires dependency injection of the repository with mock failure responses — ensure the test harness supports this before integration testing begins. The service depends on the notification repository, which must be stable first. All three mutation operations (mark-read, mark-all-read, clear-all) need explicit test coverage including both success and failure paths.

The operationId-based success/failure callbacks suggest async operation tracking — this pattern must be consistent with how the BLoC consumes events to avoid race conditions when multiple operations are triggered in quick succession, particularly mark-all-read followed immediately by clear-all.

Notification Read State Service wraps notification-repository mutation calls with an optimistic-update pattern coordinated via the notification-bloc. On markAsRead(notificationId), it emits an optimistic BLoC event immediately to update UI state, fires the async repository call, then emits onOperationSuccess or onOperationFailure based on the result — triggering a revert event on failure. markAllAsRead(userId) and clearAll(userId) follow the same pattern but operate on full collections. The getUnreadCount(userId) method delegates directly to the repository without optimistic logic since it is a read-only query.

The operationId parameter passed to success/failure callbacks enables correlation between async completions and the originating BLoC event in cases where multiple operations are in-flight. Ensure read_at timestamps use UTC and are set server-side (via Supabase default or trigger) rather than client-side to prevent clock-skew issues in audit trail integrity.