Crate Map
Moonpool is organized as a layered workspace. Core defines runtime-neutral provider contracts. Simulation and hyper integrations build on those contracts without depending on each other. The facade gathers the pieces applications usually need.
Dependency Diagram
moonpool
(facade crate)
/ | \
v v v
moonpool-core moonpool-sim moonpool-hyper moonpool-prometheus
^ / | \ |
| v v v |
| moonpool- moonpool- moonpool- |
| assertions buggify explorer |
| | |
| libc |
+----------------------------------+
moonpool-sim-examples (raw TCP, axum, tonic, topology)
moonpool-wasm-demo (browser simulation over raw TCP)
moonpool-calibrate (measures the real host; depends on no moonpool crate)
xtask (simulation command runner)
Library Crates
moonpool
Role: Facade crate. It re-exports core provider traits and, behind features, the simulation runtime and the namespaced hyper integration.
Use the default feature set for simulation work. A production application can
select only tokio, then add hyper if it speaks HTTP or gRPC.
moonpool-core
Role: The boundary between application logic and its runtime.
Provider traits:
TimeProviderfor sleeps, timeouts, and monotonic timeTaskProviderfor spawned futuresNetworkProviderfor TCP streams and listenersRandomProviderfor runtime-controlled randomnessStorageProviderfor file operationsProvidersfor carrying the five implementations as one bundle
The Tokio implementations provide real production I/O. Simulation supplies deterministic implementations of the same traits.
It also holds the registry-agnostic metrics vocabulary (MetricsSource,
MetricSample, SeriesRecorder) and, in metrics::query, the typed
SELECT / RATE / BUCKETIZE / MAP / REDUCE model a runner uses to declare what it
wants summarized. Both are pure std and wasm-clean. See
Application Metrics.
moonpool-assertions
Role: Antithesis-style assertion accounting with no dependencies.
The default table lives on the heap. Explorer workers can overlay a shared region so discoveries and watermarks survive process boundaries. The crate is also usable without the simulation runner and compiles to wasm.
moonpool-buggify
Role: Standalone buggify! / buggify_with_prob! fault-injection macros and
their per-run activation state, with no dependencies.
Buggify is inert by default: outside a simulation every call site evaluates to
false. moonpool-sim installs its seeded random source at the start of each
run and re-exports the macros, so production and sans-I/O code can depend on
this crate directly without pulling in the simulation runtime. buggify_knob!
stays in moonpool-sim. The crate compiles to wasm.
moonpool-sim
Role: Deterministic execution, simulated time/network/storage, chaos, process lifecycle, workloads, tracing invariants, and assertion wiring.
Key types:
SimulationBuilderconfigures processes, workloads, chaos, and iterationsSimContextexposes providers, topology, shared state, and shutdownSimWorldcoordinates lifecycle and the globalScheduler<Event>Scheduler<Event>owns monotonic logical time, same-time FIFO ordering, and cancellationNetworkSimulationowns network state, topology, faults, operations, results, and wakersStorageEngineowns persistent files, independent handles, disk behavior, operations, results, and wakersProcessdescribes the system under testWorkloaddescribes the test driverInvariantchecks cross-process properties from trace eventsNetworkConfigurationandStorageConfigurationtune fault surfaces
The optional default-on exploration feature connects the runner to
moonpool-explorer. Disable it for wasm32-unknown-unknown.
moonpool-hyper
Role: Run real hyper, axum, and tonic stacks over provider-backed streams.
Key types:
HyperIoadapts a futures-io stream to hyper’s I/O traitsHyperExecutorroutes hyper tasks throughTaskProviderHyperTimeranswers hyper clock requests throughTimeProviderTowerToHyperServicebridges tower and hyper servicesReconnectingChannelprovides a lazy reconnecting h2 client channelH2Serverserves h2 connections with provider-driven shutdown and timing
Client and server features are individually selectable. The featureless crate contains only the runtime adapters.
moonpool-prometheus
Role: Report the metrics your application already keeps as simulation output.
Key types:
PrometheusSourcewraps aprometheus::Registryand implementsMetricsSourceSimCounter,SimGauge,SimHistogramare instrumented handles that record every mutation on the simulated clockSimTimertimes a histogram observation fromTimeProvider, not the wall clock
It depends only on moonpool-core, never on moonpool-sim, so the adapter is equally usable in production and moonpool-sim stays wasm-clean. See Application Metrics.
moonpool-explorer
Role: Frontier exploration through replay recipes, discovery journals, exemplars, and a bounded worker pool.
The explorer depends on moonpool-assertions for the shared discovery contract
and on libc for fork, waitpid, and shared mappings. It remains optional so
the simulation runtime can build on wasm.
Workspace Applications
moonpool-sim-examples
Runnable examples cover raw TCP topology, axum over HTTP/1, tonic over HTTP/2, and exploration workloads. They are demonstration binaries, not library dependencies.
moonpool-wasm-demo
A single-seed raw TCP ping/pong simulation compiled to wasm. It exports a JSON timeline consumed by the browser animation embedded in the book.
moonpool-calibrate
A calibration CLI that measures the real host and prints
LatencyDistribution constants for moonpool’s storage and network latency
knobs. Uniquely in this workspace it depends on no moonpool crate at
runtime: the measurement path is raw std::fs, std::net, and
std::time::Instant, because measuring through the providers would measure the
simulator rather than the machine. See
Calibrating Against a Real Machine.
xtask
Cargo automation for discovering and running simulation binaries:
cargo xtask sim listcargo xtask sim run <filter>cargo xtask sim run-all