fabro/lib/apps/fabro-cli/tests/it
Bryan Helmkamp 16354186fa
Run a Petri run in the worker process over the HTTP store
When `fabro run __run-worker` finds its run's stored spec names Petri, the
new `petri_worker` module executes it through `fabro_petri::engine` over
`HttpRunStore`, leased for a launch id the worker mints and logs at start.
`--mode start` loads the admitted graphs through the client's blob read;
`--mode resume` continues the run from its records. The worker's existing
services carry over: the control channel's cancel and SIGTERM/SIGINT cancel
Petri's root invocation politely, a lost control channel cancels the run
and is reported once it settles, and pause, unpause and steer are received
and ignored with a warning until their adapters land. The model client
comes from the worker's catalog and vault snapshot for the providers whose
credentials resolve, and the lifecycle events (`run.starting`,
`run.running`, then `run.completed` or `run.failed`) go through the client
as the legacy worker's do.

Scenario tests against the real binary: a command-only Petri run executes
in the worker a foreground server launched, its records reach
`petri_records` over the HTTP store and its lease ends with the worker; and
a run whose server and worker are both killed mid-stage resumes in a new
worker after the server restarts, with one `run.completed`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 21:20:22 -04:00
..
cmd Accept the CLI snapshots the engine flag and the listed diagnostics changed 2026-09-17 20:34:22 -04:00
scenario Run a Petri run in the worker process over the HTTP store 2026-09-17 21:20:22 -04:00
support Add the engine flag and record the engine on the run spec 2026-09-17 20:02:47 -04:00
workflow Fix the twin-mode hook and arc e2e tests 2026-09-14 09:41:05 -06:00
main.rs refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00