Skip to content

After a crash, clips that finished rendering come back marked Rendered, not just Captured - #1343

Merged
ccoventry merged 1 commit into
devfrom
fix/catch-up-keeps-rendered-861
Nov 7, 2026
Merged

ccoventry merged 1 commit into
devfrom
fix/catch-up-keeps-rendered-861

Conversation

@ccoventry

Copy link
Copy Markdown
Owner

Release note: Fixed: after Studio or the PC goes down mid-batch, clips that had already finished rendering come back marked Rendered, not just Captured.

What happened

The WSOD25 batch rendered 35 clips while capturing, then the PC froze. On the next start the catch-up marked all 129 captured clips Captured, the 35 finished ones included: their Rendered marks had only been in the open, unsaved project.

What changes

The backend already says when a take was rendered and deleted while the batch ran (VerifiedBlock.rendered, #861), and nothing read it. applyCaughtUpBatch now marks those highlights Rendered. The toast says how many each way: "94 highlight(s) marked Captured. 35 highlight(s) marked Rendered: their clips were finished before it closed."

Status still only moves forward, with the same rules as before.

Not covered

  • A take whose clip finished but that was kept on disk (with "only when space is needed", a take stays until room is needed): rendered is only set once a take is gone, so it's still marked Captured. Its render history is in its dodstudio_take.json, so the backend could check that too; left for a follow-up if wanted.
  • Projects already caught up, like diceWSOD25main.dodstudio's 35: the catch-up ran before this fix and doesn't run again.

Test done

  • batch_catch_up.test.js: a rendered take's highlights become Rendered; the toast counts both ways and leaves Rendered out when there are none (20 pass).
  • npm run test:unit (1,432 passed), eslint (no errors). No e2e spec covers the catch-up.

Not tested in Studio: it needs a batch cut short after a render.

🤖 Generated with Claude Code

…ndering, not just Captured

The backend already reports a take rendered and deleted while the batch ran
(VerifiedBlock.rendered, #861); applyCaughtUpBatch now marks its highlights
Rendered instead of Captured, and the toast says how many each way.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ccoventry

Copy link
Copy Markdown
Owner Author

Tested in a real Studio (tauri dev from this branch, its own port, app-data folder and web view profile; the user's settings.json hash unchanged after):

  • Seeded a batch that "ran while Studio was closed", built from last night's WSOD25 manifest: 3 blocks whose takes were rendered and deleted (only their dodstudio_take.json with a finished render, copied to a test folder), 2 never recorded, started from a copy of diceWSOD25main.dodstudio.
  • On start: ran while Studio was closed: 3/5 takes on disk, and the toast: "3 of 5 clips are on disk. 3 highlight(s) marked Rendered: their clips were finished before it closed. Marked them in the project wsod25_copy.dodstudio."
  • The project copy, saved: those 3 highlights went from Captured to Rendered (verified, not by hand); everything else as before (235 Pending, 126 Captured, 3 Rendered). The manifest was rewritten as unwatched, so it doesn't run again.

@ccoventry
ccoventry merged commit f628957 into dev Nov 7, 2026
10 checks passed
@ccoventry
ccoventry deleted the fix/catch-up-keeps-rendered-861 branch November 7, 2026 23:08
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.

1 participant