Module context 

Typed per-delivery context exposing native Redis metadata, one struct per transport, plus the subscription-scoped batch context the batch forms read.

A handler reads native Redis metadata for the message it is processing by compile-time Field key, with no hashing, boxing, or downcasting. The runtime builds the context value once per delivery (via BuildContext) from the concrete broker message; the handler reads a field with ctx.context(key), or binds one as a parameter with the core Ctx<K> extractor.

A batch handler gets one context per batch instead (BuildBatchContext), carrying only what the whole subscription shares. Per-delivery data has no place there, since a batch spans many deliveries: an entry id or a position rides the batch’s own elements.

This is purely additive. A handler that declares the default () context is unaffected: the blanket impl BuildContext<M> for () still applies, so opting in costs nothing to those who do not.

What is exposed

Only genuinely-native metadata that is not already reachable off the payload or HeaderMap is surfaced here:

• StreamContext (Redis Streams) - the entry id this delivery was read at, the position that redelivers it, the consumer group, and the group’s reposition handle. The native reclaim delivery-count and idle time stay header-surfaced (DELIVERY_COUNT_HEADER / IDLE_MS_HEADER) and are deliberately not duplicated.

• StreamBatchContext (Redis Streams, batch forms) - the consumer group and its reposition handle, both subscription-scoped.

• PubSubContext (Redis Pub/Sub) - the concrete channel the message arrived on and whether it matched through a PSUBSCRIBE pattern (for a pattern subscription the channel differs from the registered glob).

• PoolContext (every form) - the broker’s connection pool alone, which keys::FredPool reads. The key also reads StreamContext, StreamBatchContext and PubSubContext, so a handler takes the pool beside a form’s own keys; Ctx<keys::FredPool> goes after the form’s key there, because the first Ctx key names the handler’s context.

Lists carry nothing native beyond their payload and headers, so a list handler reads the pool off PoolContext or stays on the () default.

Examples

use ruststream_fred::stream::prelude::*;
use serde::Deserialize;

#[derive(Deserialize)]
struct Order {
    id: u64,
}

#[subscriber(RedisStream::new("orders").group("workers"))]
async fn handle(order: &Order, ctx: &mut Context<'_, StreamContext>) -> HandlerOutcome {
    // The entry id reads like `1700000000000-0`.
    println!(
        "order {} read at {} through {}",
        order.id,
        ctx.context(keys::EntryId),
        ctx.context(keys::ConsumerGroup)
    );
    HandlerOutcome::ack()
}

#[ruststream::app]
fn app() -> impl App {
    RustStream::new(AppInfo::new("orders", "0.1.0")).with_broker(
        RedisBroker::standalone("redis://localhost:6379"),
        |b| {
            b.include(handle);
        },
    )
}

Modules

keys

Compile-time Field keys, one per native field, read with ctx.context(key).

Structs

PipelineContext

The per-delivery context of a .pipeline() subscription: the delivery’s round and the broker’s connection pool.

PoolContext

The per-delivery context that carries the broker’s connection pool and nothing else: what a handler taking Ctx<keys::FredPool> alone reads, on every form.

PubSubContext

Per-delivery context for a Redis Pub/Sub delivery (RedisPubSubMessage).

StreamBatchContext

Batch context for a batched Redis Streams subscription: what the whole subscription shares.

StreamContext

Per-delivery context for a Redis Streams delivery (RedisMessage).