The Oxidizer Project

This repository contains a set of crates that help you build robust highly scalable services in Rust.

• The Oxidizer Project
  • Crates
  • About this Repo
    • Adding New Crates
    • Publishing Crates
    • Documenting Crates
    • CI Workflows
    • Pull Request Gates
    • Local Verification
  • Trademarks

Crates

These are the primary crates built out of this repo:

• anyspawn - A generic task spawner compatible with any async runtime.
• anyspawn_azure - Azure SDK async runtime and process executor backed by an anyspawn spawner and a tick clock.
• allocation_hints - Allocator-independent heap ownership and scoped allocation hints.
• arty - Single-threaded, thread-aware application runtime.
• bytesbuf - Types for creating and manipulating byte sequences.
• bytesbuf_io - Asynchronous I/O abstractions expressed via bytesbuf types.
• cachet - A composable, customizable multi-tier caching library with rich feature support.
• cachet_memory - In-memory cache tier backed by Moka for the cachet caching library.
• cachet_service - Layered service integration for the cachet caching library.
• cachet_tier - Core cache tier trait and abstractions for building cache backends.
• compressors - Streaming compression and decompression over bytesbuf byte sequences.
• data_privacy - Mechanisms to classify, manipulate, and redact sensitive data.
• fetch - "Universal, composable and resilient HTTP client."
• fetch_azure - Azure SDK HTTP transport backed by the fetch HTTP client.
• fetch_hyper - Hyper-based HTTP transport utilities for fetch.
• fetch_options - Options types for 'fetch' crate.
• fetch_winhttp - WinHTTP-based HTTP transport for the fetch client (Windows only).
• fundle - Compile-time safe dependency injection for Rust.
• http_compression - HTTP request and response body compression and decompression.
• http_extensions - Shared HTTP types and extension traits for clients and servers.
• http_path_template - Parser for the google.api.http path-template grammar.
• internity - Blazingly fast string interning with compact handles, compact storage, and concurrent fill support.
• layered - A foundational service abstraction for building composable, middleware-driven systems.
• metabench - Run Criterion, Gungraun, Linux perf, Intel VTune, and allocation benchmarks together and combine their reports.
• multitude - Fast and flexible arena allocator.
• ohno - High-quality Rust error handling.
• performables - Thread-aware synchronization and ownership primitives.
• plurality - A highly efficient pooling memory allocator.
• rallocator - A high-performance global allocator with passive allocation hints and telemetry.
  • Supported platforms
  • Design guide
  • Implementation guide
• seismograph_cli - Live monitoring and snapshot tools for seismograph telemetry.
• seismograph - High-performance process telemetry with extensible snapshot sources.
• seismograph_io - Structured I/O event instrumentation for Seismograph.
• seismograph_protocol - Local monitor protocol and discovery model for Seismograph.
• seismograph_rallocator - Rallocator snapshot source for seismograph.
• seismograph_runtime - Runtime and task lifecycle instrumentation for Seismograph.
• recoverable - Recovery information and classification for resilience patterns.
• rest_over_grpc - Automatically transcode gRPC services to REST/JSON endpoints.
• routerama - Blazingly fast HTTP route resolution and query string processing.
• seatbelt - Resilience and recovery mechanisms for fallible operations.
• seatbelt_http - HTTP-specific extensions for the seatbelt crate.
• templated_uri - Standards-compliant URI handling with templating, safety validation, and data classification
• thread_aware - Facilities to support thread-isolated state.
• thread_aware_core - Stable core traits and types for thread-aware state.
• tick - Provides primitives to interact with and manipulate machine time.
• uniflight - Coalesces duplicate async tasks into a single execution.

About this Repo

The following sections explain the overall engineering process we use in this repo.

To set up a local PC environment capable of exercising all the tooling used by this repo's development processes, you can follow the guide in DEVELOPMENT.md.

Adding New Crates

Adding a new crate to this repo is done by running the scripts\add-crate.ps1 script. It will prompt you for a few bits of state, and then will get everything wired up that needs to be.

The add-crate script does the following:

• Adds an entry for the crate to the Crates section in this README file.

• Adds an entry for the crate to the top-level CHANGELOG.md file.

• Prepares a README.md file for the crate, setup for use with cargo-doc2readme with a set of appropriate CI badges.

• Creates an empty CHANGELOG.md file for the crate, which will later get populated by the scripts\release-packages.ps1 script.

• Creates placeholder logo.png and favicon.ico files for the crate, which you're expected to replace with legit crab-themed logo and icon.

Publishing Crates

Releasing new versions of crates to crates.io is handled by an internal Microsoft automation process. To release a new version of any crate, follow this simple process:

1. Make sure the changes you want to release have all been committed to the repo.

2. Create a branch off of main.

3. Run ./scripts/release-packages.ps1 -Packages '<crate_name>@<change_type>' to update versions and changelogs. The change type for each package is one of breaking, nonbreaking, patch, or an explicit version like 1.0.0. To release several crates together, list them all in the same -Packages argument (for example, 'foo@nonbreaking','bar@patch'); the script plans the entire release up-front.

4. Create a PR like normal to push changes out.

Once your PR is merged, automation will kick in. It will tag the commit and push the crate to crates.io.

Documenting Crates

We want our crates to have world-class documentation such that our customers can enjoy discovering and using our features. We expect our Rust code to be fully documented in the normal Rust way, and we introduce two doc-related automation processes:

• The README.md file in each crate's directory is auto-generated from the crate-level documentation. We use the cargo-doc2readme tool which reads the crate docs, resolves intra-doc links, and generates the README.md file using a shared template. A pull request gate ensures the README.md file always reflects the latest crate documentation.

• The CHANGELOG.md file in each crate's directory is auto-generated from the commits to a crate's directory by the scripts/release-packages.ps1 script.

To generate documentation locally with all features enabled (including feature-gated items), run:

just anvil-doc-build --open

Anvil uses the repository's selected stable toolchain for this command. The script generates documentation and opens it in your default browser.

CI Workflows

Cargo Anvil owns Rust verification:

• anvil-pr.yml runs impact-scoped pull request and merge-group checks across the supported operating-system and architecture matrix.
• anvil-scheduled.yml runs full-workspace backstops and longer checks.

Both workflows invoke the same generated just anvil-* recipes developers use locally. Codecov reports remain available for detailed inspection, while the Anvil coverage gate is authoritative.

Pull Request Gates

The Anvil pull request tier covers formatting, linting, manifest policy, documentation, dependency policy, SemVer analysis, external-type exposure, tests, coverage, examples, MSRV compatibility, Miri, cargo-careful, Loom, Bolero, and mutation testing. Run the complete tier locally with:

just anvil-pr

Local Verification

Run just anvil-setup once to install the toolchains and tools selected by the Anvil catalog. Useful focused commands include:

just anvil-build
just anvil-clippy
just anvil-fmt --fix
just anvil-readme --fix
just anvil-spellcheck
just anvil-pr-fast

Tool versions are generated in justfiles/anvil/versions.just and updated with Cargo Anvil. Do not maintain a second tool-version list.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.