fabro/lib/apps/fabro-server
Bryan Helmkamp b5ebb472ae
Launch a worker for a Petri run and resume it after a server restart
`execute_run` no longer runs a Petri run in the server process by default:
it takes the subprocess path a legacy run takes, and `worker_exited` still
releases the worker's lease when the process ends. The in-process path
stays under the handler-registry test override, so the scenario tests need
no worker binary; it now honours the managed run's execution mode.

At startup, `reconcile_incomplete_runs_on_startup` hands a Petri run the
previous server left in flight (runnable, starting, running, blocked or
paused, with no cancel pending) back to a worker instead of failing it:
`PetriRuns::release_for_restart` ends the dead worker's lease from outside,
which fences it should it still be alive, the run is asked to start again
as a resume (`run.start_requested` with `resume`, then `run.runnable`, the
pair the API's resume appends), and the managed run is registered in
resume mode when Petri's store holds the run, else in start mode. Full
workspace recovery is the plan's F3.5 and is noted in the module docs.

Tests: the restart reconcile releases the lease, rewrites the history, and
launches the worker with `--mode resume`; a worker's HTTP store leases for
its launch id over the loopback server.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 21:20:22 -04:00
..
migrations Run fabro exec through pebble's command-line session 2026-09-11 20:51:01 -06:00
src Launch a worker for a Petri run and resume it after a server restart 2026-09-17 21:20:22 -04:00
tests Launch a worker for a Petri run and resume it after a server restart 2026-09-17 21:20:22 -04:00
build.rs refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00
Cargo.toml Run a workflow through Petri in the server, behind the engine flag 2026-09-17 20:27:44 -04:00