Stems archive: failedReason is plumbed to the client then replaced with a hardcoded 'check your connection' error

[dylanjeffers]

Summary

failedReason is plumbed from the archiver worker all the way to the client and then discarded. Both download-archive surfaces render one hardcoded string regardless of what actually failed:

"Something went wrong. Please check your connection and try again."

• GetStemsArchiveJobStatusResponse in useDownloadTrackStems.ts declares failedReason?: string
• The archiver's getJobStatus populates it, and removeInternalStatusFields strips only returnvalue, so it reaches the client intact
• DownloadTrackArchiveModal.tsx:33 and the mobile drawer both render messages.error, a fixed string

Impact

The message is actively misleading. During the 2026-07-28 outage the archiver queue was wedged server-side, and every affected user was told to check their own internet connection — for seven hours. It also sends people into a pointless retry loop against a failure that retrying cannot fix.

Proposed fix

Surface failedReason when present, and distinguish server-side job failure from client-side network failure. A generic fallback is still right when failedReason is absent, but it should not assert a cause we haven't established.

Worth pairing with better copy for the timeout case specifically (job never started vs. job failed mid-run are different user stories).

[dylanjeffers]

Live example of why this matters, 2026-07-28 ~06:05–06:10 UTC.

A user hit "Something went wrong. Please check your connection and try again." on the Audius Summer Cypher contest. Investigating it required cluster access, because the message carries no information: the archiver had no job at all for that track — the request never reached the service. The archiver pod had just been rescheduled onto a new GKE node (restart at 05:57:24Z), and a transient Cloudflare 522 to the origin was reproducible in that window (1 of 13 probes; 12/12 clean immediately after).

This surfaces a case the issue as written doesn't cover. There are two distinct failure paths and only one of them has a failedReason to surface:

1. The job ran and failed — jobStatus.state === 'failed', failedReason is populated. Surfacing it is what this issue describes.
2. The request never produced a job — initiateDownloadFailed (the POST itself failed), or the job-status poll errors/times out. There is no failedReason because there is no job.

Today both collapse into the same "check your connection" string. Path 2 is the one that fired here, and the message was actively misleading in a second way: it was neither the user's connection nor an archive failure, it was a transient server-side blip during a node replacement — retrying immediately would have worked, which is the opposite of what "check your connection" suggests.

Suggested shape:

• job failed with a reason → show the reason
• job failed without one → generic archive-failure copy, retry offered
• couldn't reach the archiver / poll errored → "couldn't start your download, try again" — explicitly retryable, no blame on the user's network
• timed out (isTimedOut) → distinct copy; the job may still be running server-side, so "still preparing, check back" is more accurate than "failed"

Related: the mobile side didn't even reach path 4 until #14539.