salvor-server 0.5.0

Salvor control plane: an HTTP + server-sent-events server over the durable runtime
docs.rs failed to build salvor-server-0.5.0
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

Salvor control plane: an HTTP and server-sent-events server over the durable runtime.

This crate is a thin network surface: submit an agent definition, start a run, stream its events, resume or recover or resolve it, list and inspect runs. Durability stays where it belongs, in the one Rust process that owns the event store; the server holds handles and constructs a [salvor_runtime::Runtime] per request, so nothing about a run lives in the process that a restart would lose. Clients (the v0.3 Python and TypeScript SDKs, the dashboard) are thin because the guarantees are not theirs to keep.

The HTTP contract, every route and shape and the event framing, is the deliverable those clients build against. It is specified in API.md alongside this source, and each handler module documents its own routes.

Shape of the crate

  • [AppState] is the shared handle: the store, the agent registry, the run-driver bookkeeping, and the [AgentFactory] seam that turns a submitted definition into a live agent.
  • [build_router] wires the routes and the auth layer; [serve] binds and runs them.
  • [dispatch] holds the state-to-verb mapping shared with the CLI, so the two surfaces agree on what a run's state means.
  • The handler modules (agents, runs, sse) own their endpoints; [error::ApiError] is the one error envelope they all return.

Auth

One optional shared-secret bearer, a single-tenant posture. With a token set on the state, every route requires Authorization: Bearer <token>; without one, the server trusts its caller and a reverse proxy owns auth. No user model, no RBAC.