feat(acquisition): a restored run can be carried on - #204
Merged
Merged
Conversation
"there is no way to resume a timelapse." After a restart the checkpoint puts every embryo back where it was — its ending, its interval, its count — but the loop that images them is gone, and start() would begin a new run. The run view drew the restored embryos as "running · next now" with a Stop each, over nothing. Now the orchestrator can continue a restored run. Every embryo still going is due now (the interruption was of unknown length), numbering carries on from the checkpoint so the volumes on disk are never written over, the DIC channel keeps its clock, and the run keeps its started_at. The Resume route carries a restored run on, and still resumes a paused one; it wakes the session's standing_timelapse tactic back to active and re-adopts it, so a later Stop marks it done again. In the run view a restored run says "interrupted — press Resume run to carry on", its rows say "waiting" with no next-time and no Stop, and the actions show one button: Resume run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows #203. That PR put the run's state back after a restart — every embryo's ending, interval and count — but the loop that images them is gone with the old process, and
start()begins a new run. So the run view showed the restored embryos as "running · next now" with a Stop each, over nothing, and offered no way on.Orchestrator.
can_continue()(idle, with embryos still going) andcontinue_run(): every embryo still going is due now (the interruption was of unknown length), numbering carries on from the checkpoint so the volumes on disk are never written over, the DIC channel keeps its clock, the run keeps itsstarted_at, and a new perception run is opened. Paused → plainresume(); nothing restored → says so.Routes. The status carries
resumable.POST /api/devices/timelapse/resumecarries a restored run on ({continued: true}) and still resumes a paused one; it also wakes the session'sstanding_timelapsetactic from done back to active and re-adopts it, so a later Stop marks it done again (the ids the orchestrator kept for it do not survive a restart).Run view. A restored run says "interrupted — press Resume run to carry on"; its rows say waiting with no next-time and no per-embryo Stop; the actions show one button, Resume run. Rows of a live run are unchanged.
Tests: an orchestrator that imaged a few rounds, whose task is cancelled (not stopped) with the checkpoint on disk; a fresh orchestrator loads it,
can_continue(), continues, and every embryo's count goes up from where it was, never from t1 again. Plus paused→resume, nothing-to-continue, completed embryos excluded, the two routes, and the view's wiring. 9 tests intests/test_timelapse_continue.py.🤖 Generated with Claude Code