---
id: ML-169.1
title: "Phase 3: Concurrent state change safety audit"
status: To Do
assignee: []
created_date: "2026-05-08 08:59"
updated_date: "2026-05-11 06:46"
labels:
  - audit
  - ready
dependencies: []
references:
  - lib/music_library/worker/
  - lib/music_library/records.ex
  - lib/music_library_web/components/record_form.ex
parent_task_id: ML-169
priority: medium
---

## Description

<!-- SECTION:DESCRIPTION:BEGIN -->

Audit whether background Oban worker record mutations are safely reflected in LiveView state without data corruption or stale UI.

Key risks to investigate:

1. Worker-broadcast consistency: do all record-modifying workers call Records.notify_update/1?
2. Form edit + background update race: editing in RecordForm modal while worker updates record
3. Double-update handling: two workers updating same record simultaneously
<!-- SECTION:DESCRIPTION:END -->

## Acceptance Criteria

<!-- AC:BEGIN -->

- [ ] #1 Every record-modifying Oban worker audited for notify_update/1 call after success (RefreshCover, PopulateGenres, GenerateRecordEmbedding, RecordRefreshMusicBrainzData, ImportFromMusicbrainzRelease, ImportFromMusicbrainzReleaseGroup, all RecordAll\* batch workers)
- [ ] #2 Workers that do NOT modify records confirmed as correctly NOT broadcasting (PruneAssets, ApplyScrobbleRules, all ArtistRefresh\*, etc.)
- [ ] #3 Form edit + background update race evaluated: trace what happens when RecordForm holds stale @record assign while worker broadcasts {:update, record} to parent Show page
- [ ] #4 Double-update race evaluated: confirm both handle_info calls apply safely (workers touch different fields, second wins)
- [ ] #5 ArtistLive.Show confirmed as intentionally not handling {:update, record} (artist updates use ArtistLive.Form → {:saved, artist_info} path)
- [ ] #6 Findings report written as a Backlog.md document with file:line references, severity ratings, and fix recommendations
<!-- AC:END -->