Skip to content

feat(release-editor): show upload progress and add an Upload button - #1223

Merged
scobru merged 1 commit into
devfrom
claude/sweet-newton-mfgt1u
Sep 10, 2026
Merged

scobru merged 1 commit into
devfrom
claude/sweet-newton-mfgt1u

Conversation

@scobru

@scobru scobru commented Sep 9, 2026

Copy link
Copy Markdown
Owner

Saving a release fires a chain of requests — release metadata, cover art, then the audio, then the per-track edits — and the audio is the slow half, tens of megabytes a file. All the artist got was a disabled Save button: no way to tell an upload in flight from a stuck one, on the one action of the app that routinely takes minutes.

What changed

Release editor (/admin/release/new, /admin/release/:id/edit)

  • Queued audio is listed in the tracklist with its size, and the toolbar grows an Upload N files button that sends the audio on its own, without saving-and-closing the release — creating the release first when it does not exist yet, since a file needs somewhere to land (a title is required, and asked for if missing).
  • A progress bar under the toolbar reports the whole chain: which file is going up, how far its bytes have got, and how much of the batch is left. Each queued row carries its own bar, so one stalled file is visible rather than averaged away.
  • Audio now goes up one request per file instead of one request for the batch. The browser reports bytes for a request as a whole, so a single 400 MB request could only ever say "somewhere between 0 and 100%", and one failure partway through took every file with it. Per file, a failure costs only that file and the rest stay queued for a retry.
  • Save and Publish end in a toast rather than in silence.
  • The pending-upload list rendered <div> cards inside <tbody> (invalid nesting) and was duplicated by a second list below the table; it is now proper rows, and the lower list became the upload strip that starts the transfer.

Dialogs

  • Upload Tracks counted finished files, so a single large file sat at 0% until it was completely done. It now weights progress by bytes, shows a bar per file, and leaves the finished bar next to the result.
  • Upload Sample had no progress at all; it has the same bar now.

Shared pieces

  • components/ui/UploadProgress.tsx — the one bar every upload surface uses (clamped percentage, indeterminate mode when the browser reports no total, theme-consistent colours).
  • uploadProgressConfig in services/api/client.ts gives every upload endpoint the same optional onProgress; wired into tracks, cover, additional artworks, samples and sample packs.
  • formatBytes in utils/format.ts.

Testing

  • npx vitest run — 257 tests pass across 38 suites. The one failing suite, src/pages/__tests__/Collab.test.tsx, fails to load for an environment reason (vite-plugin-node-polyfills shim resolution against the improvised dependency install in this container) and fails identically on a clean checkout of this branch's base.
  • New: src/components/ui/UploadProgress.test.tsx (4 tests) and src/pages/__tests__/AdminReleaseEditor.test.tsx (3 tests — the Upload button appears only with audio queued, an upload reports its transfer and creates the release first, and a failed file stays queued for a retry).
  • Extended: UploadTracksModal.test.tsx with a test that the bar follows reported bytes rather than the file count.
  • npx tsc --noEmit and npx vite build both clean. npm run lint could not run in this container (its ESLint dependencies are not installed).

Docs (docs/adding-music.md and the Italian twin) describe the new button and bars; CHANGELOG and both versions bumped (6.1.0 / webapp 2.17.0).

🤖 Generated with Claude Code

https://claude.ai/code/session_01DtNRuZAEw5XA5HXBAJvs4x


Generated by Claude Code

Saving a release fires a chain of requests — release metadata, cover art,
then the audio, then the per-track edits — and the audio is the slow half,
tens of megabytes a file. All the artist got was a disabled Save button:
no way to tell an upload in flight from a stuck one, on the one action of
the app that routinely takes minutes.

- Queued audio is listed in the tracklist with its size, and the toolbar
  grows an "Upload N files" button that sends the audio on its own, without
  saving-and-closing the release (creating the release first when it does
  not exist yet, since a file needs somewhere to land).
- A bar under the toolbar reports the whole chain: which file is going up,
  how far its bytes have got, and how much of the batch is left. Each queued
  row carries its own bar, so one stalled file is visible rather than
  averaged away.
- Audio goes up one request per file instead of one request for the batch:
  the browser reports bytes for a request as a whole, so a single 400 MB
  request could only ever say "somewhere between 0 and 100%", and one
  failure partway through took every file with it. Per file, a failure costs
  only that file and the rest stay queued for a retry.
- Save and Publish end in a toast rather than in silence.
- The pending-upload list rendered <div> cards inside <tbody>; it is now
  proper rows, and the duplicate list below it became the upload strip.

The same bar reached the Upload Tracks and Upload Sample dialogs. The tracks
dialog counted finished files, so a single large file sat at 0% until it was
completely done; it now weights progress by bytes and leaves the finished bar
next to the result. `uploadProgressConfig` in the API client gives every
upload endpoint the same optional `onProgress`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DtNRuZAEw5XA5HXBAJvs4x
@scobru
scobru marked this pull request as ready for review September 10, 2026 07:28
@scobru
scobru merged commit 15f84a0 into dev Sep 10, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants