Struct Config 

pub struct Config {
    pub data_dir: PathBuf,
    pub node: u32,
    pub target_block_bytes: usize,
    pub max_block_age: Duration,
    pub retention: Duration,
    pub queue: usize,
    pub shards: usize,
    pub wal: Option<Arc<Wal>>,
}

Engine configuration.

Note what is not reachable from config.rs: target_block_bytes and max_block_age are derived constants, not settings. They are the two numbers an operator would most expect to tune and the two the engine is best placed to own, so principle 2c applies and there is no YAML key for either.

Fields

data_dir: PathBuf

node: u32

Writer identity, from mira_core::block::node_id. Makes block names unique across replicas with no coordination.

target_block_bytes: usize

Seal a block once it reaches roughly this many bytes.

max_block_age: Duration

Seal a block after this long regardless of size, so acknowledgement latency is bounded by time and not by the caller’s traffic.

retention: Duration

queue: usize

How many exports may wait for one signal’s flusher. See crate::config::Config::queue, which is where the reasoning is.

Split across shards, so the number an operator sets is still the number of decoded exports this signal can be holding.

shards: usize

How many flusher tasks one signal runs, each with its own channel, open block and block sequence.

One per core, not one per resource hash — section 4’s “A note on sharding” is explicit about which of those is the right unit, and the reason is that resource cardinality in real fleets is bimodal, so a hash gives a permanently hot shard and a small-file explosion in the tail. Files per flush interval should be a function of core count, known at startup, not of the customer’s topology.

One, not available_parallelism, by default: main resolves the real number from ingest.shards and the core count, and everything that builds a Config by hand — every unit test, every e2e node — wants the deterministic one block per seal that a single shard gives.

wal: Option<Arc<Wal>>

The write-ahead log, shared by all three signals, or None to acknowledge on the block publish as Mira always has.

One Option rather than a separate durability setting, because the two are the same decision: with a log, an export is recoverable the moment it is framed and there is nothing left for the acknowledgement to wait for; without one, the publish is the only thing that makes it recoverable. A flag that let those disagree would only be able to express wrong answers.

Off by default. Turning it on would trade read-your-writes away — see mira_core::wal’s module docs — were it not for mira_core::query::search_open, which scans the flusher’s open builder alongside the sealed blocks and buys it back.

Trait Implementations

impl Default for Config

fn default() -> Self

Returns the “default value” for a type.