fix(api): enforce is_streamable on the stream and download endpoints - #1023
Merged
Conversation
The track response has always reported `is_streamable: false` when a track is
deleted or its owner is no longer active (a self deactivation or a
trusted-notifier delist), but 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, which served the complete 7.3MB mp3.
Guard the stream and download endpoints, and leave non-streamable tracks out
of the playlist m3u8 rather than emitting URLs the stream endpoint now
rejects. Return 404 rather than 403 so these aren't distinguishable from a
missing track.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
Production exposurePulled the delist data to size this up. The reported account ( Notably there is no Platform-wide, currently delisted accounts with tracks that still stream:
~26,000 tracks across ~1,100 suppressed accounts are reachable and playable today through Worth weighing on merge: the vast majority of this is copyright-strike enforcement, which argues for landing sooner rather than later. 🤖 Generated with Claude Code |
dylanjeffers
added a commit
to AudiusProject/apps
that referenced
this pull request
Aug 20, 2026
…der or unfurl (#14570) ## Problem Reported by Marcus: [audius.co/rehoxx/just-for-tonight-wmellark-hoonds](https://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: false` whenever 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 because `TrackMetadata` didn'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_streamable` appeared 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 - Stop omitting `is_streamable`; add it to `TrackMetadata` as optional. - New `isTrackUnavailable` helper in common holds the semantics in one place. - Gate the track page on it across **web desktop, mobile web, and native mobile**. - SSR `+onRenderHtml` serves generic metadata, `noindex`, and no embed player when the flag is false. Two deliberate details: - The check is an explicit `=== false`. Not every track source populates the field, and an absent value must not read as unavailable. - Deleted tracks are excluded from the helper, so they keep their existing "deleted by artist" page. ## 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 as `og:image`, and `twitter: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. `tsc` and eslint clean across common/web/mobile.⚠️ The **native mobile** change is typecheck- and lint-verified only — it hasn't been run in a simulator. It mirrors the existing `ProfileScreen` deactivated branch structurally, but the layout is unproven. ## Related The API-side half is [AudiusProject/api#1023](AudiusProject/api#1023) — the stream endpoint didn't enforce `is_streamable` either, so the raw audio was reachable regardless of what the UI showed. ## Known gaps, not addressed here - An inactive artist's **profile** page still reads "This Account No Longer Exists / has been deleted" — same wrong-copy problem, keyed on `is_deactivated`. - Profile SSR still emits the artist's name, bio, and picture in og tags. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 20, 2026
dylanjeffers
added a commit
to AudiusProject/apps
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 21, 2026
Follow-up to #1023. #1023 guarded `/v1/tracks/{id}/stream` and `/download`, but that only closed two routes. `dbv1.TracksKeyed` builds the `Stream`/`Download`/`Preview` media links with no reference to `is_streamable`, so `/v1/tracks/{id}` and `/v1/resolve` still hand out a working signed content-node URL for tracks whose owner is deactivated or delisted by the trusted notifier. Verified against the delisted account from the original report (`audius.co/rehoxx/just-for-tonight-wmellark-hoonds`, track `ENxw4`): `/stream` correctly 404s, but the `stream.url` in the track response returned `206 audio/mpeg` with the full file. ## Change Hoist the `is_streamable` expression above the media-link block and gate all three links on it. This matches the empty-cid case directly above, which already leaves the link nil so the endpoints report the track as unavailable — same intent, and now the two reasons sit under one comment. `preview` is included because a preview clip is still the artist's audio. ## Notes - Scoped to non-streamable tracks only — ordinary tracks are untouched, covered by `TestGetTrack_StreamableKeepsMediaLinks`. - Content nodes reject signatures older than 48h ([`serve_blob.go:544`](https://github.com/AudiusProject/go-openaudio/blob/main/pkg/mediorum/server/serve_blob.go#L544)), so URLs already in the wild age out on their own. The leak was that the API minted a fresh one on every request. - The client-side half of this is apps#14570, which is deployed. ## Test plan - `TestGetTrack_NonStreamableOmitsMediaLinks` — deactivated owner and deleted track both get `stream`/`download`/`preview` = null - `TestGetTrack_StreamableKeepsMediaLinks` — active owner still gets all three, signed - Full `go test ./api/...` passes 🤖 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 free
to 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
The track response has always reported
is_streamable: falsewhen 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.gosetsIsStreamable: !rawTrack.IsDelete && !user.IsDeactivated).Nothing enforced it.
/v1/tracks/{id}/streamstill 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 returningis_streamable: falsefor that track.Change
/v1/tracks/{id}/streamonIsStreamable./v1/tracks/{id}/download— closing only the stream path leaves the identical audio one endpoint away.m3u8rather than emitting URLs the stream endpoint now rejects.Returns
404rather than403so these aren't distinguishable from a missing track.Tests
Two new cases in
v1_track_stream_test.gocovering a deactivated owner and a deleted track — both assert404and noLocationheader. Fullgo 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 — the shared adapter was stripping
is_streamablebefore it reached web or mobile, so the player never saw it either.🤖 Generated with Claude Code