Expand description
Executions: watching a capability call that takes longer than a request should be held open for.
Nothing here is a second way to do anything. An execution runs a capability of the one registry, through the one executor, and the only thing it adds is that the call has an identity, a lifecycle, a stream of typed events and a cancellation flag — so that a browser, an agent or a terminal can watch it happen instead of waiting for a response.
capability! ──► CapabilityRegistry ──► Context::execute ──► the handler
│ ▲ │
│ │ │ Progress
└──► ExecutionEngine ───┘ ▼
│ ExecutionEvent
▼ │
ExecutionStore ◄─────────────────────────┘
│
┌──────────────────┼───────────────────┐
▼ ▼ ▼
executions.get executions.events the WebSocket
(HTTP · MCP · CLI) (HTTP · MCP · CLI) (the Cockpit)The layering is the point, and it runs one way. The domain produces events; the store
keeps and fans them out; a transport renders them. crate::http::events is an
adapter over this module and contains no execution logic, which is what makes an audit
trail, a notifier or a second protocol something that subscribes rather than something
that has to be threaded through the engine.
One plane per checkout, not one per process. majordomus run executes in its own
process, and when a server already serves the checkout it reports the execution there
(ExecutionStore::adopt, ExecutionStore::report), so the server’s listing, the
Cockpit and the live channel show it with the pid that ran it; a server that stops
hearing from it fails it rather than showing it running for ever. With no server, the
run says on stderr that nothing else can see it. A run never starts a server.
What it is not: a job system. There is no durable queue, no retry, no schedule and no
execution that outlives the process that accepted it. The store says so — its limits
are typed and its behaviour at each limit is defined — and store::Limits is where a
durable store would be substituted, because nothing above it names a Mutex.
Re-exports§
pub use engine::ExecutionEngine;pub use engine::SubmitError;pub use event::EventPayload;pub use event::ExecutionEvent;pub use event::PROTOCOL_VERSION;pub use model::Actor;pub use model::ActorKind;pub use model::Execution;pub use model::ExecutionDiagnostic;pub use model::ExecutionError;pub use model::ExecutionId;pub use model::ExecutionState;pub use model::LogStream;pub use model::ProgressView;pub use model::RepositoryRef;pub use model::StepState;pub use model::StepView;pub use redact::redact;pub use sink::Progress;pub use store::AdoptError;pub use store::CancelOutcome;pub use store::Delivery;pub use store::EventPage;pub use store::ExecutionStore;pub use store::Filter;pub use store::Limits;pub use store::ReportOutcome;pub use store::Seed;pub use store::REPORT_HEARTBEAT;pub use store::REPORT_SILENCE;
Modules§
- engine
- The engine: what turns a capability call into an execution anybody can watch.
- event
- The typed execution event: one envelope, a closed set of payloads, and a version.
- model
- What an execution is: its identity, the states it may be in, and the snapshot every transport answers with. Plain data with no transport type in it and no handle to a running thread: a snapshot is taken under the store’s lock and read afterwards.
- redact
- One redaction, driven by the schema.
- sink
- What a handler reports with, and how it learns it should stop.
- store
- Where executions live while this process does: the snapshots, the retained event history, and the subscribers.