Skip to content

fix(track): render unavailable tracks as a 404 instead of a custom tombstone - #14572

Open
dylanjeffers wants to merge 1 commit into
mainfrom
fix/track-404-skeleton
Open

fix(track): render unavailable tracks as a 404 instead of a custom tombstone#14572
dylanjeffers wants to merge 1 commit into
mainfrom
fix/track-404-skeleton

Conversation

@dylanjeffers

Copy link
Copy Markdown
Contributor

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

…mbstone

#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.
Per Ray's feedback on the original report, these should look like any other
missing page instead.

The API already returns 404 for these tracks specifically so they can't be told
apart from one that never existed (api#1023). Making the web page a real 404
finishes that: the client reuses the existing `navigate(NOT_FOUND_PAGE)` path
that a failed track fetch already takes, and SSR renders a not-found skeleton
with 404 meta tags.

The render-time guard stays, returning null rather than the tombstone. The
redirect fires from an effect, which runs after the first paint, so without it
the track's title and artwork would flash on screen before the redirect landed.

Removes the now-unused UnavailableTrackPage, and moves its server twin to
not-found-page/ServerNotFound with the 404 copy.

Mobile (React Native) and the embed player keep their existing treatment:
neither has a distinct 404 screen to route to, so their unavailable state
already is the not-found equivalent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Aug 21, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: bc61854

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

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