Enum SchemaCachePolicy 

#[non_exhaustive]
pub enum SchemaCachePolicy {
    Disabled,
    Cached {
        capacity: NonZeroUsize,
        subject_ttl: Option<Duration>,
    },
}

How the default cache ages and bounds what it holds.

The two halves of the registry’s answer expire differently, and that is not a preference but a property of the service: a schema id is immutable. The registry assigns an id per distinct schema definition, by content - registering a new version of a subject mints a new id and leaves the old one resolving to the old schema for ever, and registering an identical schema under a different subject hands back the id it already had. A subject’s latest version, by contrast, moves whenever someone registers one.

“Per registry” is really per schema context: a registry can carry several, and each numbers its ids from one, so the same id means different schemas in two of them. This was checked against a live registry - the same schema registered in the default context and in a named one both came back as id 1. It bounds what this cache is: keyed by id, it is correct for a client that stays inside one context, which is what a client addressing plain subject names does. An app that reaches across contexts through one client, by writing :.context:subject subject names, needs a client per context rather than one cache spanning them.

So an id-keyed entry can never go stale and needs no expiry - a TTL over it could only cause a refetch that returns the identical bytes - while a subject-keyed entry can, and is the only thing the subject_ttl of Cached governs. Confluent’s own clients scope their latest.cache.ttl.sec to exactly the latest-version caches for the same reason.

What ids still need is a bound. A consumer meets one id per writer version it is sent, which is small in a healthy topology and unbounded in a broken one (a producer registering a schema per message), so the cache is capped and evicts in insertion order. Evicting an id that is still in use costs one refetch and never a wrong answer, which is what makes plain insertion order enough here and a recency policy not worth its bookkeeping.

Examples

A producer that notices a newly registered version of a subject within five minutes, without a restart:

use std::time::Duration;

use ruststream_rdkafka::prelude::*;
use ruststream_rdkafka::{SchemaCachePolicy, SchemaFrame, SchemaRegistry};

fn app() -> impl App {
    let registry = SchemaRegistry::new("http://localhost:8081").cache_policy(
        SchemaCachePolicy::Cached {
            capacity: nonzero!(256usize),
            subject_ttl: Some(Duration::from_secs(300)),
        },
    );
    RustStream::new(AppInfo::new("orders", "0.1.0"))
        .publish_layer(SchemaFrame::new(registry))
        .with_broker(
            KafkaBroker::new(["localhost:9092"]).default_group("orders-svc"),
            |b| {
                b.include(confirm);
            },
        )
}

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

Disabled

Nothing is remembered: every lookup reaches the registry.

This is a real configuration, not a zero TTL wearing a disguise - for a process that must hold no schema state, or a test that wants every call observable. It has one consequence worth knowing before choosing it: a synchronous codec reads the cache and cannot await a miss, so AvroCodec::registry and SchemaFramed cannot work under it. The transcoding path, whose lookups are all async, works unchanged.

Cached

Ids are remembered up to capacity, and a subject’s resolved version for subject_ttl.

Fields

capacity: NonZeroUsize

The most id-keyed schemas held at once; the oldest is dropped past it.

subject_ttl: Option<Duration>

How long a subject’s resolved version is trusted before the next async lookup re-resolves it. None never re-resolves, which is Confluent’s own default.

This governs the async lookups only (warm and the publish-side transcode). A codec’s subject is resolved once, when the broker connects, and stays put: its encode is synchronous and cannot re-resolve, and a producer changing the schema it writes mid-process is a deliberate act, not something to absorb silently between two messages.

Trait Implementations

impl Clone for SchemaCachePolicy

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for SchemaCachePolicy

impl Debug for SchemaCachePolicy

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for SchemaCachePolicy

fn default() -> Self

Ids kept up to 1000 (Confluent’s own default bound), subjects never re-resolved (Confluent’s own default TTL).

impl Eq for SchemaCachePolicy

impl PartialEq for SchemaCachePolicy

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for SchemaCachePolicy