Module embedded 

Embedded-mode entrypoints for assay-engine.

Use case: a parent binary wants to compose engine into its own axum::Router rather than running engine standalone via crate::run.

use assay_engine::embedded;
use assay_engine::config::EngineConfig;
use std::path::Path;

let cfg = EngineConfig::from_file(Path::new("engine.toml"))?;
let engine = embedded::build(cfg).await?;
// Mount engine.router on parent's listener
// Use engine.pool for parent's queries (engine confines its
//   writes to its own schemas)

The standalone crate::run is implemented as a thin wrapper around build + a serve loop; standalone behaviour is unchanged.

Compared to the previous (now-closed) PR exposing four

pub fn build_*_ctx_* helpers

Embedded mode is a first-class concept here: one type, one function, one symmetric migrate helper. Internal ctx-builders (build_auth_ctx_{pg,sqlite}, build_vault_ctx_{pg,sqlite}) stay pub(crate) — they are implementation details. Preconditions that prevent operator lockout (no operator users + no admin api-keys + no external issuers) are enforced inside build and cannot be skipped.

Structs

EmbeddedEngine

Engine composed for embedding into a parent binary. See module docs.

Enums

EmbeddedPool

Backend-typed pool. Engine’s internal code paths are backend- specific (PG advisory locks, SQLite ATTACH for multi-module DB files); we expose typed pools so downstream can dispatch on the variant explicitly rather than guess.

Functions

build

Build engine for embedding. Internally:

migrate

Run engine + per-module schema migrations against the configured backend. No runtime state is built, no background tasks are spawned. Idempotent — calling on an up-to-date schema is a no-op.