ML-169.11: archive as invalid

2026-05-23 20:23:01 +01:00
parent 1ccd9ccc91
commit 5c80a6d6ad
1 changed files with 9 additions and 0 deletions
@@ -4,6 +4,7 @@ title: "Fix: Correlated subqueries in ListeningStats.recent_activity"
 status: To Do
 assignee: []
 created_date: "2026-05-19 11:48"
+updated_date: "2026-05-23 15:48"
 labels:
  - perf
  - fix
@@ -64,3 +65,11 @@ Consider a batch post-processing approach:
 - [ ] #4 Performance improvement measurable via QueryReporter
 - [ ] #5 Existing tests for ListeningStats.recent_activity pass
 <!-- AC:END -->
+
+## Implementation Notes
+
+<!-- SECTION:NOTES:BEGIN -->
+
+Validation on 2026-05-23: The task is not valid as written. `tracks_with_record_info_query/0` still has three correlated subqueries, but commit d8c84e787b5acc50db0e265630193a392540a5f2 intentionally introduced the correlated-subquery shape after benchmarking against the dev DB (104k tracks), improving `recent_activity(tz, 100)` from 38.98 ms to 2.87 ms. Follow-up commits 9f4135661e6a70c85824de9fefd472d551ec86ea and cfd267627c6ddeb73514c7f1883d78c3cc5247c4 changed the scalar record lookups into `matching_records` JSON while keeping the same performance-oriented pattern. A fresh Tidewave Benchee check on the current dev DB returned matching results for a batch-post-processing prototype, but the prototype was slower: current correlated `recent_activity/2` averaged 2.30 ms vs 7.41 ms for the prototype (3.22x slower). Targeted regression suite `mix test test/music_library/listening_stats_test.exs` passed (44 tests). Recommendation: archive this task as an invalid/false-positive audit finding rather than implement AC #1.
+
+<!-- SECTION:NOTES:END -->