music_library/backlog/tasks/ml-169.1 - Phase-3-Concurrent-state-change-safety-audit.md

id, title, status, assignee, created_date, updated_date, labels, dependencies, references, parent_task_id, priority

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

Description

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

Acceptance Criteria

• #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