Skip to content

fix(track): honor is_streamable so inactive artists' tracks don't render or unfurl - #14570

Merged
dylanjeffers merged 1 commit into
mainfrom
fix/track-honor-is-streamable
Aug 20, 2026
Merged

fix(track): honor is_streamable so inactive artists' tracks don't render or unfurl#14570
dylanjeffers merged 1 commit into
mainfrom
fix/track-honor-is-streamable

Conversation

@dylanjeffers

Copy link
Copy Markdown
Contributor

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: 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 — 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

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>
@changeset-bot

changeset-bot Bot commented Aug 20, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 691fb00

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

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>
@dylanjeffers
dylanjeffers merged commit 1dd3f5e into main Aug 20, 2026
17 checks passed
@dylanjeffers
dylanjeffers deleted the fix/track-honor-is-streamable branch August 20, 2026 17:04
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant