boatramp_node/
lib.rs

1//! Node assembly for boatramp.
2//!
3//! The `boatramp` binary was historically the only place that turned parsed
4//! configuration into a running node (store + backends + handler runtime +
5//! reconcile loops + router). That assembly is not reachable as a library, so an
6//! embedder — or an in-process fidelity test — can't exercise the same wiring the
7//! `boatramp serve` binary runs (see `PLAN-node-library`).
8//!
9//! This crate is the extraction target. It starts with the parsed **config model**
10//! ([`config`]) and grows, incrementally and behaviour-preservingly, to host the
11//! `assemble(config) -> RunningNode` path. The binary re-exports [`config`] under
12//! its own `crate::config`, so moving the module here changes no call site.
13//!
14//! It depends on the concrete backend crates (Docker, storage, …) that
15//! `boatramp-server` deliberately does not, keeping `boatramp-server` a
16//! backend-agnostic library while this crate is the batteries-included assembler.
17
18pub mod auth;
19pub mod backends;
20/// The `BLOB FALLBACK ZERO-GAP OK` mutation-verified gate (blob-backend migration Part 2). Compiled
21/// ONLY under the `blob-fallback-gate-mutation` feature (the CI gate lane): it drives the real
22/// [`FallbackStorage`](boatramp_storage::FallbackStorage) composite over real `FsStorage` tempdir
23/// backends + a real `DeployStore` for the GC-refusal invariant, and prints the marker only on a
24/// clean run.
25#[cfg(feature = "blob-fallback-gate-mutation")]
26pub mod blob_fallback;
27/// Offline, node-local blob-backend migration (`boatramp blob migrate`) — the copy engine over
28/// the [`Storage`](boatramp_core::Storage) primitives. Relocated into `boatramp-storage` in
29/// v0.6.3 (so the daemon-mediated `POST /api/blob-drain` can drive it too); re-exported here so
30/// the offline CLI + `build_blobs` callers keep compiling unchanged (`boatramp_node::blob_migrate`).
31/// Gated on the exact set of node features that activate the optional `boatramp-storage` dep (every
32/// blob backend implies `fallback`; `cloudflare-kv`/`slatedb`/`handlers` pull it directly), so the
33/// re-export exists precisely when `boatramp_storage` is linkable — which is exactly when the offline
34/// `blob migrate` / `blob drain` client path (which needs a real backend) is reachable. A truly lean
35/// node (no storage) compiles fine with the re-export absent (nothing references it there).
36#[cfg(any(
37    feature = "fallback",
38    feature = "cloudflare-kv",
39    feature = "slatedb",
40    feature = "handlers"
41))]
42pub use boatramp_storage::blob_migrate;
43pub mod blobs;
44pub mod compute;
45pub mod config;
46pub mod error;
47pub use error::Error;
48pub mod handlers;
49// The managed-SQL module carries the Postgres/MySQL operator-SQL + credential machinery (sqlx) AND
50// the migration substrate. It compiles whenever a sqlx engine OR `migrate` (⇒ the embedded libsql
51// migration runner) is on, so the libsql migrate parity is reachable on a node with no external sqlx
52// engine. The sqlx-specific items inside the module stay gated on the sqlx features.
53#[cfg(any(feature = "sql-postgres", feature = "sql-mysql", feature = "migrate"))]
54pub mod managed_sql;
55// The project-scoped declarative managed-database front door (#501 Stage B): lowering
56// + the two-source merge point + the `ManagedDbDeclare` capability. Needs a sqlx engine
57// (it provisions a Postgres/MySQL managed DB).
58#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
59pub mod managed_db_declare;
60pub mod node;
61#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
62pub mod repair;
63/// Node-level base S3 credential sourcing from the `[secrets]` sealed store (#505).
64pub mod s3_credential;
65#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
66pub mod tenant_sql;
67#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
68pub mod tenant_tombstone;
69pub use node::{NodeInput, RunningNode, assemble};
boatramp_node/lib.rs

boatramp_node/
lib.rs
