Adds a REBUILD ALL FROM… button under CREATE SONG. It rebuilds every song from a chosen stage onwards, so an improvement to a stage reaches existing songs without rebuilding each one by hand.
API
POST /api/rebuild-all takes a force_from stage and queues an ordinary rebuild for each song, with its inputs unchanged and force_stage set to that stage. That's what Restart from does for one song, so a rebuild-all job runs through the same path as a single rebuild.
Choosing "each song" needs some care:
A job that has been rebuilt is skipped. Its rebuild is now the song, possibly under a new name, so including the old job would also rebuild the song under its former name.
When the same song was submitted more than once, only the latest job counts, since they share a work directory.
Songs still queued or running are skipped.
With stage acquire, songs whose uploaded video no longer exists are skipped. This is the same check a single rebuild makes.
GET /api/rebuild-all returns those songs (id, title, artist, status, whether the current job is itself a rebuild, and when it finished). The POST takes an optional ids list to rebuild only the songs ticked in the dialog; leaving it out rebuilds every song. A selected job that has been rebuilt since the dialog opened is reported as skipped rather than rebuilt twice.
The response lists the queued job ids and any skipped songs with the reason.
UI
The button opens a dialog with a stage picker and a list of the songs, all ticked. Each row shows whether the song was built or rebuilt and when, so songs already rebuilt by hand are easy to untick. An "All songs" box toggles the lot. Songs in progress are listed but can't be ticked. A count follows the selection, and the button is disabled when nothing is ticked, because an empty selection sends no ids and the API would read that as every song. Rebuilding everything from acquire can take hours, so the count is there to make that cost visible before confirming. After submitting, the sidebar notes how many rebuilds were queued and why any were skipped.
Screenshots of the dialog and of the queue just after confirming are in the session's shared folder.
Testing
New endpoint tests cover the candidate list, rebuilding only the selected songs, a selected job that has since been rebuilt, every song being rebuilt with unchanged inputs, rebuilt parents being skipped, the latest job winning for a song submitted twice, in-progress songs being skipped, a missing upload being skipped for acquire, and unknown or missing stages being rejected.
test_rebuild_mode_reuses_the_one_form counted <form> tags, so the dialog's own small form broke it. It now checks there is one song form, which is what it was guarding.
I drove the real page in Chromium against a seeded server (built, rebuilt and in-progress songs). In-progress songs were disabled and unticked, the rebuilt song was labelled as such, unticking updated the count and half-ticked the "All songs" box, unticking everything disabled the button, and submitting queued only the ticked songs. The page raised no script errors.
Full suite passes, except test_version (needs the package installed) and the #18 flake.
**Summary generated by LLM agent**
Adds a **REBUILD ALL FROM…** button under CREATE SONG. It rebuilds every song from a chosen stage onwards, so an improvement to a stage reaches existing songs without rebuilding each one by hand.
## API
`POST /api/rebuild-all` takes a `force_from` stage and queues an ordinary rebuild for each song, with its inputs unchanged and `force_stage` set to that stage. That's what **Restart from** does for one song, so a rebuild-all job runs through the same path as a single rebuild.
Choosing "each song" needs some care:
- A job that has been rebuilt is skipped. Its rebuild is now the song, possibly under a new name, so including the old job would also rebuild the song under its former name.
- When the same song was submitted more than once, only the latest job counts, since they share a work directory.
- Songs still queued or running are skipped.
- With stage `acquire`, songs whose uploaded video no longer exists are skipped. This is the same check a single rebuild makes.
`GET /api/rebuild-all` returns those songs (id, title, artist, status, whether the current job is itself a rebuild, and when it finished). The POST takes an optional `ids` list to rebuild only the songs ticked in the dialog; leaving it out rebuilds every song. A selected job that has been rebuilt since the dialog opened is reported as skipped rather than rebuilt twice.
The response lists the queued job ids and any skipped songs with the reason.
## UI
The button opens a dialog with a stage picker and a list of the songs, all ticked. Each row shows whether the song was built or rebuilt and when, so songs already rebuilt by hand are easy to untick. An "All songs" box toggles the lot. Songs in progress are listed but can't be ticked. A count follows the selection, and the button is disabled when nothing is ticked, because an empty selection sends no ids and the API would read that as every song. Rebuilding everything from `acquire` can take hours, so the count is there to make that cost visible before confirming. After submitting, the sidebar notes how many rebuilds were queued and why any were skipped.
Screenshots of the dialog and of the queue just after confirming are in the session's shared folder.
## Testing
- New endpoint tests cover the candidate list, rebuilding only the selected songs, a selected job that has since been rebuilt, every song being rebuilt with unchanged inputs, rebuilt parents being skipped, the latest job winning for a song submitted twice, in-progress songs being skipped, a missing upload being skipped for `acquire`, and unknown or missing stages being rejected.
- `test_rebuild_mode_reuses_the_one_form` counted `<form>` tags, so the dialog's own small form broke it. It now checks there is one song form, which is what it was guarding.
- I drove the real page in Chromium against a seeded server (built, rebuilt and in-progress songs). In-progress songs were disabled and unticked, the rebuilt song was labelled as such, unticking updated the count and half-ticked the "All songs" box, unticking everything disabled the button, and submitting queued only the ticked songs. The page raised no script errors.
- Full suite passes, except `test_version` (needs the package installed) and the #18 flake.
When an update improves a stage, existing songs only pick it up when each
is rebuilt from that stage. POST /api/rebuild-all queues an ordinary
rebuild with unchanged inputs for the current job of every song: jobs that
were themselves rebuilt are skipped, as are songs still in progress and
songs whose upload is gone when the stage is acquire. The sidebar button
opens a dialog to pick the stage and confirm the count.
The dialog now lists the songs it would rebuild, all ticked, each with when
it was last built and whether that was a rebuild, so songs already rebuilt
by hand can be unticked. GET /api/rebuild-all returns that list, so the
page no longer repeats the server's rule for which job stands for a song,
and POST takes the ticked job ids. A selected job that has since been
rebuilt is reported as skipped rather than rebuilt twice.
branderson
approved these changes 2026-10-10 19:33:05 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary generated by LLM agent
Adds a REBUILD ALL FROM… button under CREATE SONG. It rebuilds every song from a chosen stage onwards, so an improvement to a stage reaches existing songs without rebuilding each one by hand.
API
POST /api/rebuild-alltakes aforce_fromstage and queues an ordinary rebuild for each song, with its inputs unchanged andforce_stageset to that stage. That's what Restart from does for one song, so a rebuild-all job runs through the same path as a single rebuild.Choosing "each song" needs some care:
acquire, songs whose uploaded video no longer exists are skipped. This is the same check a single rebuild makes.GET /api/rebuild-allreturns those songs (id, title, artist, status, whether the current job is itself a rebuild, and when it finished). The POST takes an optionalidslist to rebuild only the songs ticked in the dialog; leaving it out rebuilds every song. A selected job that has been rebuilt since the dialog opened is reported as skipped rather than rebuilt twice.The response lists the queued job ids and any skipped songs with the reason.
UI
The button opens a dialog with a stage picker and a list of the songs, all ticked. Each row shows whether the song was built or rebuilt and when, so songs already rebuilt by hand are easy to untick. An "All songs" box toggles the lot. Songs in progress are listed but can't be ticked. A count follows the selection, and the button is disabled when nothing is ticked, because an empty selection sends no ids and the API would read that as every song. Rebuilding everything from
acquirecan take hours, so the count is there to make that cost visible before confirming. After submitting, the sidebar notes how many rebuilds were queued and why any were skipped.Screenshots of the dialog and of the queue just after confirming are in the session's shared folder.
Testing
acquire, and unknown or missing stages being rejected.test_rebuild_mode_reuses_the_one_formcounted<form>tags, so the dialog's own small form broke it. It now checks there is one song form, which is what it was guarding.test_version(needs the package installed) and the #18 flake.