Summary
Clicking "View on Discogs" for an album opens a 404. Example (artist: Naoya Matsuoka, album: Watermelon Dandies, Discogs release ID 5743831):
- Broken link shown:
https://www.discogs.com/release/r5743831
- Correct link:
https://www.discogs.com/release/5743831 (Discogs redirects a bare numeric release ID to its canonical slugged URL, so the slug isn't required — confirmed by manually removing the leading r, which alone made the link resolve)
Root cause
The stray leading r is SoulSync's own internal ID-routing tag (core/discogs_client.py's _tag_discogs_album_id, added in #848 to fix the master/release collision in #847) leaking into a public-facing field. It's meant to stay an internal detail for _discogs_album_endpoints() routing between /masters/{id} and /releases/{id}, but leaks out through two independent paths:
- The artist-detail discography grid —
_build_artist_detail_release_card() (core/metadata/discography.py) never includes external_urls in its output, even though Album.from_discogs_release() already computes the correct, fully-slugged URL from Discogs' own uri field at parse time. The card is left with only the tagged id.
- The persisted
albums.discogs_id DB column — the background auto-match worker (core/discogs_worker.py's _update_album()) writes the tagged id straight into the database. It's read back verbatim (no un-tagging) by get_artist_full_detail() and handed to the frontend, where getServiceUrl() does a plain string interpolation with no idea the tag exists. This is the one that fires for an already-matched library album's "View on Discogs" badge, not just an unowned discography-grid card.
Steps to reproduce
- Use Discogs as (or one of) the metadata source(s).
- Open an artist whose album has been auto-matched to Discogs, or browse an artist's Discogs discography grid.
- Click "View on Discogs" on an album.
Expected: the real Discogs release page loads.
Actual: 404 — the URL has a stray r (or m, for a master release) prefixed to the numeric ID.
Impact
Any album sourced from or matched against Discogs whose "View on Discogs" link a user clicks — both the discography-browsing view and an already-matched library album's badge.
I have a fix (verified against real Discogs API data, plus new regression tests) and will open a PR against dev referencing this issue. Thanks for SoulSync!
Summary
Clicking "View on Discogs" for an album opens a 404. Example (artist: Naoya Matsuoka, album: Watermelon Dandies, Discogs release ID
5743831):https://www.discogs.com/release/r5743831https://www.discogs.com/release/5743831(Discogs redirects a bare numeric release ID to its canonical slugged URL, so the slug isn't required — confirmed by manually removing the leadingr, which alone made the link resolve)Root cause
The stray leading
ris SoulSync's own internal ID-routing tag (core/discogs_client.py's_tag_discogs_album_id, added in #848 to fix the master/release collision in #847) leaking into a public-facing field. It's meant to stay an internal detail for_discogs_album_endpoints()routing between/masters/{id}and/releases/{id}, but leaks out through two independent paths:_build_artist_detail_release_card()(core/metadata/discography.py) never includesexternal_urlsin its output, even thoughAlbum.from_discogs_release()already computes the correct, fully-slugged URL from Discogs' ownurifield at parse time. The card is left with only the taggedid.albums.discogs_idDB column — the background auto-match worker (core/discogs_worker.py's_update_album()) writes the tagged id straight into the database. It's read back verbatim (no un-tagging) byget_artist_full_detail()and handed to the frontend, wheregetServiceUrl()does a plain string interpolation with no idea the tag exists. This is the one that fires for an already-matched library album's "View on Discogs" badge, not just an unowned discography-grid card.Steps to reproduce
Expected: the real Discogs release page loads.
Actual: 404 — the URL has a stray
r(orm, for a master release) prefixed to the numeric ID.Impact
Any album sourced from or matched against Discogs whose "View on Discogs" link a user clicks — both the discography-browsing view and an already-matched library album's badge.
I have a fix (verified against real Discogs API data, plus new regression tests) and will open a PR against
devreferencing this issue. Thanks for SoulSync!