Uh oh!
There was an error while loading. Please reload this page.
fix(track): honor is_streamable so inactive artists' tracks don't render or unfurl - #14570
Merged
Conversation
The API has always reported `is_streamable: false` for tracks whose owner is no longer active - either the artist deactivated their own account or the account was delisted by the trusted notifier - but the shared adapter listed the field in its omit list, so it was stripped before reaching web or mobile. With no signal, the track page rendered and played normally, and SSR served the track's title and artwork to crawlers and social unfurls. Stop dropping the field, add it to TrackMetadata, and gate the track page on it behind a shared `isTrackUnavailable` helper. Deleted tracks are excluded so they keep their existing "deleted by artist" treatment. The copy deliberately says nothing about the account: the same flag covers a self deactivation and a delisted account, and we shouldn't tell users an artist deleted their account when moderation suppressed it. Reported by Marcus for audius.co/rehoxx/just-for-tonight-wmellark-hoonds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
dylanjeffers added a commit
to AudiusProject/api
that referenced
this pull request
Aug 20, 2026
…1023) ## Problem The track response has always reported `is_streamable: false` when a track is deleted or its owner is no longer active — either the artist deactivated their own account, or the account was delisted by the trusted notifier ([`dbv1/tracks.go`](https://github.com/AudiusProject/api/blob/main/api/dbv1/tracks.go) sets `IsStreamable: !rawTrack.IsDelete && !user.IsDeactivated`). Nothing enforced it. `/v1/tracks/{id}/stream` still redirected to a signed content-node URL, so the audio stayed fully reachable to anyone holding the link. Verified against a delisted account in production: the endpoint served the complete **7,352,685 bytes** of `audio/mpeg`, despite the same API returning `is_streamable: false` for that track. ## Change - Guard `/v1/tracks/{id}/stream` on `IsStreamable`. - Same guard on `/v1/tracks/{id}/download` — closing only the stream path leaves the identical audio one endpoint away. - Leave non-streamable tracks out of the playlist `m3u8` rather than emitting URLs the stream endpoint now rejects. Returns `404` rather than `403` so these aren't distinguishable from a missing track. ## Tests Two new cases in `v1_track_stream_test.go` covering a deactivated owner and a deleted track — both assert `404` and no `Location` header. Full `go test ./api/...` suite is green. ## Context Found while investigating a report from Marcus that a suppressed artist's tracks were still showing. The client-side half is in [AudiusProject/apps#14570](AudiusProject/apps#14570) — the shared adapter was stripping `is_streamable` before it reached web or mobile, so the player never saw it either. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
dylanjeffers added a commit
that referenced
this pull request
Aug 20, 2026
…der (#14571) Follow-up to #14570, which gated the web and mobile track pages on `is_streamable`. The embed player is its own app and was missed — it still rendered the full card (title, artist, artwork, play button) for a track whose owner deactivated their own account or was delisted by the trusted notifier. AudiusProject/api#1023 already made `/v1/tracks/{id}/stream` 404, so the player couldn't actually play these. It just showed the metadata and then failed silently on press. ## Change Route non-streamable tracks into the existing not-available treatment (the same path a 404 takes), with its own copy rather than reusing the deleted-by-creator string — the same flag covers a self deactivation and a delisted account, and we shouldn't tell listeners the creator removed a track when moderation suppressed it. Wording matches the web tombstone from #14570. The check is an explicit `=== false`, matching `isTrackUnavailable` in common: an absent field must not read as unavailable. (The embed depends on `@audius/sdk` rather than `@audius/common`, so the helper isn't importable here.) ## Verification Ran against prod data using `audius.co/rehoxx/just-for-tonight-wmellark-hoonds` (`ENxw4`), the track from the original report: | | | |---|---| | `card` | "This track can no longer be streamed on Audius." | | `compact` | same | | `tiny` | "Track Unavailable" | Both routes covered — hash id (`getTrack`) and permalink (`getBulkTracks`). A streamable trending track still renders normally with artwork and play button. `vite build`, `eslint`, and `jest` all pass. ## Note The remaining gap is server-side: `/v1/tracks/{id}` still returns a signed content-node URL for these tracks, which AudiusProject/api#1024 fixes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
dylanjeffers added a commit
that referenced
this pull request
Aug 24, 2026
…mbstone (#14572) Follow-up to #14570, per Ray's feedback in the #eng thread on the original report: > It should render as a 404 skeleton probbaly but this is fine. #14570 gave tracks whose owner is no longer active — a self deactivation, or an account delisted by the trusted notifier — a bespoke "Track Unavailable" page. This makes them a plain 404 instead. That's also the more consistent answer. AudiusProject/api#1023 deliberately returns 404 rather than 403 for these tracks so they can't be told apart from a track that never existed; the web page was the one surface still announcing that something specific used to be there. ## Change - **Client**: reuse the existing `navigate(NOT_FOUND_PAGE)` path that a failed track fetch already takes, rather than importing a page component. - **SSR**: render a not-found skeleton with 404 meta tags (`Not Found` / `404 - Page not found`), still `noIndex`, still no embed player. - Removes `UnavailableTrackPage`; moves its server twin to `not-found-page/ServerNotFound` with the 404 copy. The render-time guard stays but returns `null` instead of the tombstone. The redirect fires from an effect, which runs after first paint — without the guard the track's title and artwork would flash on screen before the redirect landed. That was the one thing the old `return <UnavailableTrackPage />` got for free. ## Scope Mobile (React Native) and the embed player are unchanged. Neither has a distinct 404 screen to route to, so their unavailable state already *is* the not-found equivalent — pointing them at a "404" would just mean different copy for the same thing. ## Verification Against prod data via the SSR dev server, using `rehoxx/just-for-tonight-wmellark-hoonds` (the track from the original report): - Crawler fetch: `og:title` = `Not Found • Audius`, `og:description` = `404 - Page not found`, `robots: noindex`, no `twitter:player`, no signed `cidstream` URL - Browser: lands on `/404` with the standard 404 page; track title never appears in the rendered body - A normal trending track still renders its full page `tsc --noEmit` and `eslint` both clean. ## Note The SSR hydration payload still carries the track's `title` and `orig_filename`, since it's the raw API response. Pre-existing and unchanged by this PR — flagging it as a separate thing worth deciding on. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Reported by Marcus: audius.co/rehoxx/just-for-tonight-wmellark-hoonds still renders and plays, even though that artist's account is no longer active.
The API already says it shouldn't. It returns
is_streamable: falsewhenever a track is deleted or its owner is inactive. But the shared adapter listed the field in its omit list — introduced in #14388 under "Fields from API that are omitted in this model," simply becauseTrackMetadatadidn't have the field, not for any deliberate reason.So the answer was computed by the API, sent over the wire, and deleted on arrival.
is_streamableappeared exactly twice in the entire client codebase, and one of those was the line dropping it. With no signal, the track page rendered normally, played normally, and SSR served the track's title and artwork to crawlers and social unfurls.Change
is_streamable; add it toTrackMetadataas optional.isTrackUnavailablehelper in common holds the semantics in one place.+onRenderHtmlserves generic metadata,noindex, and no embed player when the flag is false.Two deliberate details:
=== false. Not every track source populates the field, and an absent value must not read as unavailable.Copy
This Track Isn't Available/This track can no longer be streamed on Audius.Deliberately says nothing about the account. The same flag covers an artist deactivating their own account and an account being suppressed by moderation, and we shouldn't tell users an artist deleted their account when that isn't what happened.
Verification
SSR output for the reported URL now returns
robots: noindex,og:title"Track Unavailable • Audius", the default logo asog:image, andtwitter:card: summary— no track title, artist name, or artwork. Desktop and mobile web checked against the live prod API; a normal trending track still renders fully.tscand eslint clean across common/web/mobile.ProfileScreendeactivated branch structurally, but the layout is unproven.Related
The API-side half is AudiusProject/api#1023 — the stream endpoint didn't enforce
is_streamableeither, so the raw audio was reachable regardless of what the UI showed.Known gaps, not addressed here
is_deactivated.🤖 Generated with Claude Code