2.2 KiB
id, title, status, assignee, created_date, labels, dependencies, references, modified_files, parent_task_id, priority, ordinal
| id | title | status | assignee | created_date | labels | dependencies | references | modified_files | parent_task_id | priority | ordinal | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ML-169.6 | Fix: Redundant stream_insert + immediate full reload after CRUD | To Do | 2026-05-19 11:48 |
|
|
|
ML-169 | medium | 27000 |
Description
Fix redundant database query pattern where stream_insert is immediately followed by a full load_and_assign_* call that negates the benefit of the incremental insert.
Problem
After a create/save operation, the code performs a correct stream_insert (incremental insert) but then immediately calls load_and_assign_*/2 which does a full stream(..., reset: true) — completely negating the benefit of stream_insert. Same pattern exists for delete operations.
Files
lib/music_library_web/live/scrobble_rules_live/index.ex:247-253—handle_info({Form, {:created, ...})doesstream_insertthenload_and_assign_ruleslib/music_library_web/live/online_store_template_live/index.ex:195-201—handle_info({Form, {:saved, ...})doesstream_insertthenload_and_assign_templates
Impact
Wastes a database query after every create/save/delete operation. Medium severity because these are infrequent user actions (not per-keystroke or per-tick).
Fix
Remove the load_and_assign_* call after stream_insert. The stream already has the correct data. For delete, stream_delete already removes the item from the stream — no full reload needed.
Acceptance Criteria
- #1 Creating a scrobble rule inserts it into the stream without a full reload
- #2 Saving an online store template inserts it into the stream without a full reload
- #3 Deleting an item removes it from the stream without a full reload
- #4 Stream order remains correct after insert/delete operations
- #5 No duplicate items appear after create/save