Crate dynamic_config_tower 

One reading of configuration per request, as a plain tower layer.

This is the layer dynamic-config-axum is built on, published on its own because nothing in it is axum’s: it wraps any tower::Service over an http::Request, takes one Snapshot when the request begins, and puts it in the request’s extensions. tonic, plain hyper, or any tower stack can use it directly; axum adds only its extractor on top.

use dynamic_config_tower::SnapshotLayer;
use dynamic_config_web_core::sections;

SnapshotLayer::new(sections![Server])

Reading it back out is request.extensions().get::<Snapshot>(), and Snapshot::require is the form whose error says which mistake was made. The crate owns no lifecycle: loading, watching and the WatchHandle stay in main, exactly as the web-core README says.

Long-lived connections

A WebSocket upgrade, an SSE route and a streaming body all begin as an HTTP request, so the layer gives each one a snapshot — and that is correct for the handshake: whether to accept, from which configuration, is a request-scoped question. What the snapshot must not become is the connection’s configuration for life. Inside the connection loop, read fresh state per iteration or per message batch — T::current() is that read — exactly as the Python package’s Limitations chapter puts it for ASGI: a connection that lives an hour pinned to the configuration it opened with is the opposite of what any of this is for.

Macros

sections

The sections a request reads, by type.

Structs

Sections

The sections a request reads, and how to read each one.

Snapshot

What one request may read: one Arc per section, taken together.

SnapshotLayer

Takes one snapshot per request and puts it in the request’s extensions.

SnapshotService

The service SnapshotLayer wraps a stack in.

Enums

NotInScope

Why a section is not in this request’s snapshot.