Skip to main content
The unified runtime is the production entry point for MobKit. It bootstraps a Meerkat mob and MobKit’s module subsystems together, merges their event streams, and manages the combined lifecycle through a single handle.

Builder pattern

Use UnifiedRuntime::builder() to configure and start the runtime:

Required fields

Missing required fields produce UnifiedRuntimeBuilderError::MissingRequiredField with the specific field name.

Bootstrap sequence

1

Mob bootstrap

The Meerkat mob runtime starts first. Members are provisioned, wiring is established, and the mob reaches an operational state. If this fails, the builder returns UnifiedRuntimeBootstrapError::Mob.
2

Module startup

MobKit modules are spawned as subprocesses. The supervisor monitors health checks and waits for all modules to reach the Healthy state within the timeout. If module startup fails, the builder attempts to roll back the mob runtime before returning the error.
3

Event merging

Agent events from the mob and module events from MobKit are merged into a single timestamped stream, accessible through runtime.merged_events.
4

Route registration

The unified runtime automatically registers delivery routes for each mob member using the pattern mob.member.{member_id}.notification, enabling inter-member messaging through the delivery subsystem.
5

HTTP serving

The runtime composes Axum routers for the console frontend, console JSON API, console JSON-RPC, timeline SSE, agent/mob SSE, structural mob-events SSE, and blob serving into a single HTTP server.

Rollback on failure

If module startup fails after the mob has already started, the runtime performs a coordinated rollback:
  1. Attempt to shut down the mob runtime
  2. If rollback succeeds, return the original module startup error
  3. If rollback also fails, return ModuleStartupRollbackFailed containing both errors
This prevents orphaned mob processes when modules fail to start.

Runtime handle

After successful bootstrap, the builder returns a UnifiedRuntime handle with access to:

Reconciliation

The unified runtime supports reconciling member changes:
Reconciliation updates routing tables when members are added or removed from the mob, ensuring delivery routes stay in sync with the current membership.

Shutdown

Graceful shutdown tears down both systems in reverse order:
The shutdown report includes status from both the mob and module runtimes.

HTTP composition

The unified runtime composes three Axum routers:

Error hierarchy

See also