cloud/music_library
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ML-169.1: performed concurrent state change safety audit

Browse Source
This commit is contained in:
Claudio Ortolina
2026-05-19 08:33:55 +01:00
parent 2d4b82e7bb
commit 2a108660ae
2 changed files with 391 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backlog/tasks/ml-169.1 - Phase-3-Concurrent-state-change-safety-audit.md
+27 -8
View File
@@ -1,10 +1,10 @@
---
id: ML-169.1
title: "Phase 3: Concurrent state change safety audit"
status: To Do
status: In Progress
assignee: []
created_date: "2026-05-08 08:59"
updated_date: "2026-05-11 06:46"
updated_date: "2026-05-19 07:28"
labels:
- audit
- ready
@@ -13,6 +13,10 @@ references:
- lib/music_library/worker/
- lib/music_library/records.ex
- lib/music_library_web/components/record_form.ex
modified_files:
- >-
docs/audits/phase3-concurrent-state-safety/doc-26 -
Audit-Report-Concurrent-State-Change-Safety-Phase-3.md
parent_task_id: ML-169
priority: medium
---
@@ -34,10 +38,25 @@ Key risks to investigate:
<!-- 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
- [x] #1 Every record-modifying Oban worker audited for notify_update/1 call after success (RefreshCover, PopulateGenres, GenerateRecordEmbedding, RecordRefreshMusicBrainzData, ImportFromMusicbrainzRelease, ImportFromMusicbrainzReleaseGroup, all RecordAll\* batch workers)
- [x] #2 Workers that do NOT modify records confirmed as correctly NOT broadcasting (PruneAssets, ApplyScrobbleRules, all ArtistRefresh\*, etc.)
- [x] #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
- [x] #4 Double-update race evaluated: confirm both handle_info calls apply safely (workers touch different fields, second wins)
- [x] #5 ArtistLive.Show confirmed as intentionally not handling {:update, record} (artist updates use ArtistLive.Form → {:saved, artist_info} path)
- [x] #6 Findings report written as a Backlog.md document with file:line references, severity ratings, and fix recommendations
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Audit complete. Report written at docs/audits/phase3-concurrent-state-safety/doc-26.
Key findings:
- All 8 record-modifying workers correctly broadcast notify_update or broadcast_index_changed
- 18 non-record workers confirmed as correctly NOT broadcasting
- MEDIUM finding: form edit + background update race — handle_info({:update, record}) overwrites @record during :edit. Recommended fix: add live_action guard to both Show LiveViews.
- Double-update race is SAFE: Ecto changesets only UPDATE SET changed fields, SQLite serializes writes
- ArtistLive.Show confirmed intentionally not handling {:update, record}
<!-- SECTION:NOTES:END -->