From audit doc-26 (Phase 3), Recommendation #1.
2.1 KiB
id, title, status, assignee, created_date, labels, dependencies, documentation, modified_files, priority, ordinal
| id | title | status | assignee | created_date | labels | dependencies | documentation | modified_files | priority | ordinal | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ML-188 | Fix form edit + background update race in Show LiveViews | To Do | 2026-05-19 08:42 |
|
|
|
medium | 23000 |
Description
When a user is editing a record in a modal (live_action == :edit) and a background worker (e.g., PopulateGenres, RefreshCover) broadcasts {:update, record}, the Show LiveView's handle_info overwrites @record on the socket. The next save by the user can silently revert the worker's changes because the form data was based on the stale @record.
Race flow:
- User opens edit modal with record v1
- Background worker updates DB to v2, broadcasts
{:update, v2} handle_infoassigns v2 → RecordForm gets v2 viaupdate/2- User saves → stale form params overwrite worker's v2 changes in DB
Fix: Add a live_action guard to handle_info({:update, record}) in both CollectionLive.Show and WishlistLive.Show. When live_action == :edit, skip assigning the updated record and show a warning toast that the record was updated in the background. The fresh record will be loaded on the next handle_params when the user navigates away from edit mode.
Source: Audit doc-26 (Phase 3), Recommendation #1.
Acceptance Criteria
- #1 handle_info({:update, record}) skips assign(:record, ...) when live_action == :edit in CollectionLive.Show
- #2 handle_info({:update, record}) skips assign(:record, ...) when live_action == :edit in WishlistLive.Show
- #3 Warning toast shown to user when background update occurs during edit
- #4 handle_info({:update, record}) still works normally when live_action == :show
- #5 When user navigates away from edit, handle_params re-fetches fresh record with worker changes