5 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 4.8	c7adf2c87a	fix(recommendation): broaden You-might-like fallback to liked album/track artists (#790) ... The fallback pulled artists only from explicit artist-likes (general_likes_artists), but most users like albums and tracks far more than artists — so the artists row still came up thin (a couple of tiles) even with a rich library, while the albums row filled fine. Broaden both fallbacks to "entities you've shown affinity for": - artist fallback = explicit artist-likes ∪ artists of liked albums ∪ artists of liked tracks. - album fallback = explicit album-likes ∪ albums of liked tracks. New dedicated queries (ListYouMightLike{Artist,Album}FallbackForUser) replace the narrow Rediscover-fallback reuse; same projection so the Go layer still converts directly. (Aliased + fully-qualified the UNION arms — sqlc merges UNION scopes, so unqualified user_id was ambiguous across the three like tables.) Test: 12 liked TRACKS by distinct artists, no artist-likes → the artist row now fills from their artists (was empty before). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 23:55:08 -04:00
bvandeusenandClaude Opus 4.8	36786defd1	feat(recommendation): fall back to liked entities when You-might-like is thin (#790) ... The taste roll-up surfaces top-similar albums/artists, which for a heavy listener are mostly ones they already play — so the read-time dedup (vs Most Played + Rediscover + Last Played) can strip the section down to a single tile (reported on the artists row). The code was sound; the section was just starved. Adds a read-time fallback: when a You-might-like row comes up short after dedup, top it up from the user's LIKED artists/albums — a far larger pool than the 12-entity similarity roll-up, so the same exclusions still leave plenty. Reuses the existing Rediscover-fallback queries (no new SQL), applies the same exclusions (already-shown + Rediscover + Most/Last Played) so it never duplicates a tile or suggests an actively-played entity, and is best-effort (a query error leaves the section as-is). Takes effect immediately — no rebuild. A cold-start user with no likes gets nothing from the fallback, so the new-user-empty behaviour is preserved (test still passes). Test: 20 liked artists, none played → Rediscover fills 10, You-might-like fallback fills the other 10, disjoint. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 23:24:21 -04:00
bvandeusen	8b586c2e50	feat(recommendation): rework Rediscover - track-derived eligibility + daily rotation + caps ... User request 2026-06-01: the previous Rediscover only fired on explicit album/artist likes, so users who only liked at the track level got an empty Rediscover row. Also no daily rotation - the section never changed between data updates - and 25 items felt long for the Home carousel. SQL (internal/db/queries/recommendation.sql): - ListRediscoverAlbumsForUser UNIONs the existing explicit album-like signal with a new track-derived path: an album qualifies if it has >=2 liked tracks where the earliest like is >30 days old. - ListRediscoverArtistsForUser does the same with threshold 3 (artists span more releases, so the bar is higher to avoid one-hit-wonder affinities). - Both ordering switched from longest-since-last-play to a daily- stable random hash md5(entity_id || user_id || current_date) so the row randomizes but stays consistent within a day. - Fallback queries also switched to the daily-stable hash so the fallback rows don't reshuffle on every refresh. Go (internal/recommendation/home.go): - HomeRediscoverLimit dropped from 25 to 10 (carousel-sized). - rediscoverInnerLimit (30) is the per-query cap; gives headroom so the Go-layer filters don't undershoot. - applyRediscoverAlbumFilters does cross-section dedup vs Most Played (no point surfacing albums the user is actively spinning) plus a diversity cap of max 2 albums per artist (prevents one liked-but- forgotten artist dominating the row). - applyRediscoverArtistFilters does cross-section dedup vs Most Played's artist set; no diversity cap needed (one row per artist). Tests (internal/recommendation/home_integration_test.go): - TrackDerived path: 2 liked tracks >30d old + no recent plays = album appears in Rediscover. - Threshold guard: 1 liked track = album does NOT appear. - Diversity cap: 4 explicit album-likes from same artist = 2 in output. - Dedup vs MostPlayed: eligible album whose track is in MostPlayed gets filtered out. - Existing FallbackWhenSparse test preserved (semantics unchanged for recent likes that miss the >30d primary filter). Clients unchanged - they render whatever /api/home/index returns. No parity-map row needed (this is a server-internal recommendation change, not a layout divergence).	2026-06-01 00:57:40 -04:00
bvandeusenandClaude Opus 4.7	302a15a209	test(recommendation): fix mislabeled compile-time assert in home tests ... Replaces var _ = func() pgtype.UUID { ... } with var _ map[pgtype.UUID]struct{} which actually verifies map-key comparability, matching the comment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-01 17:54:40 -04:00
bvandeusenandClaude Sonnet 4.6	d25b1f9291	feat(recommendation): add HomeData composite service for /api/home ... Runs five SQL queries in parallel (recently added albums, most played tracks, last played artists, rediscover albums, rediscover artists) via goroutines with mutex-guarded first-error capture. Rediscover sections merge primary + fallback results, de-duping by pgtype.UUID map key. All HomePayload slices are non-nil so the API handler encodes [] not null. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-01 09:06:43 -04:00