Fix Apple-resolve provider filter — search results report domain, not instance #59
No reviewers
Labels
No labels
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
WulfScience-FOSS/ha-music-own!59
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "macsome_19"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root cause of the "0/186 resolved" mystery (and every prior run showing
0 resolved, since this filter was first introduced): confirmed live via
wishlist_debug.log's raw_providers diagnostic — client.music.search()
results report their top-level .provider as the bare provider DOMAIN
("apple_music"), not the specific account instance ("apple_music--2lurrtqf")
that library listings and wishlist.provider use. Comparing those directly
never matched, on any track, ever — so _apple_resolve_uri had been silently
useless since it was written, always falling back to the untranslated
foreign-provider URI (the very failure mode it was built to fix).
_tr_matches_provider() now prefers a search result's instance-level
provider_mappings when present (exact account match, same structure
fetch_ma_playlists already relies on elsewhere), falling back to a
domain-level match otherwise. Documented caveat: with more than one
account on the same provider domain (this user has two Apple Music
accounts), the domain-only fallback can't tell them apart — a real gap
only when provider_mappings is absent from the search result, which
we don't yet have live confirmation on either way. Added a
with_mappings count to the RESOLVED/NO APPLE MATCH debug lines so the
next real run's log settles that directly instead of guessing again.
Verified with unit tests against fake Track/mapping objects, including
the two-account disambiguation case.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Root cause of the "0/186 resolved" mystery (and every prior run showing 0 resolved, since this filter was first introduced): confirmed live via wishlist_debug.log's raw_providers diagnostic — client.music.search() results report their top-level .provider as the bare provider DOMAIN ("apple_music"), not the specific account instance ("apple_music--2lurrtqf") that library listings and wishlist.provider use. Comparing those directly never matched, on any track, ever — so _apple_resolve_uri had been silently useless since it was written, always falling back to the untranslated foreign-provider URI (the very failure mode it was built to fix). _tr_matches_provider() now prefers a search result's instance-level provider_mappings when present (exact account match, same structure fetch_ma_playlists already relies on elsewhere), falling back to a domain-level match otherwise. Documented caveat: with more than one account on the same provider domain (this user has two Apple Music accounts), the domain-only fallback can't tell them apart — a real gap only when provider_mappings is absent from the search result, which we don't yet have live confirmation on either way. Added a with_mappings count to the RESOLVED/NO APPLE MATCH debug lines so the next real run's log settles that directly instead of guessing again. Verified with unit tests against fake Track/mapping objects, including the two-account disambiguation case. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>