Expand description
Internal implementation crate for OxideBatch.
This crate is implementation detail. Use
oxide-batch instead.
It exists on crates.io only because the published oxide-batch facade
depends on it. Its API carries no stability promise: items may be added,
changed, or removed in any release, without a deprecation period. It has no
supported-configuration matrix, no compatibility ledger row, and no
independent release cadence.
Everything here that OxideBatch supports is re-exported from oxide-batch
under a stable path.
The crate holds immutable flow graphs and the compiled execution plans they
lower into. An application declares a FlowGraph of step and decision
nodes joined by exit-pattern transitions, then compiles it into an immutable
CompiledExecutionPlan. Compilation normalizes the graph, rejects every
structural error the accepted basic-flow contract names, and produces the
canonical manifest whose SHA-256 digest is the definition fingerprint.
The M3 graph remains acyclic. M4 adds only the accepted bounded split and
local-partition forms; nested splits, decisions inside branches, dynamic
partitioning, and remote execution remain outside this crate’s contract.
Existing one-step TaskletJob and ChunkJob definitions lower into a
compatibility plan that retains their original format-1 manifest bytes and
fingerprint.
The crate depends on no async runtime, database driver, command-line
framework, telemetry SDK, broker client, or web framework, and on no
OxideBatch crate other than oxide-batch-core. The flow engine that
executes a compiled plan, the metadata ports that persist its decisions,
and the runtime live above this crate.
§Items marked #[doc(hidden)]
Some items exist as #[doc(hidden)] pub only because the facade’s own code
was split from these types by the extraction boundary: private access that
one crate resolved by module privacy now crosses a crate boundary. They are
not part of any surface, supported or otherwise, and the facade never
re-exports one under its own name. The staged crate-extraction contract
records each one.
Structs§
- Compiled
Execution Plan - A validated, immutable execution plan.
- Decider
Revision - An application-owned revision token for one deterministic decider.
- Decision
Input Version - The version of the durable input contract one decider reads.
- Decision
Node - One deterministic decision node of a compiled plan.
- Exit
Pattern - A bounded exit-outcome pattern used to select one transition.
- Flow
Graph - An immutable declaration of the M3 flow subset.
- Flow
Transition - One declared transition edge.
- Join
Node - The structural join owned by one M4 split.
- Partition
Budget - The finite worker and connection budget for one M4 partition manager.
- Partition
Count - A finite durable partition count for one M4 partitioned step.
- Partitioned
Step Node - A bounded local partition manager and its ordinary worker-step definition.
- Pattern
Specificity - The computed specificity of one exit pattern.
- Split
Branch - One declared linear branch of an M4 split.
- Split
Budget - The finite concurrency and connection budget for one M4 split.
- Split
Node - A bounded M4 split whose branches converge at exactly one join node.
- Step
Node - One executable node of a compiled plan.
Enums§
- Flow
Node - One node of a declared flow graph.
- Flow
Selection Error - A compiled plan that cannot route one observed exit outcome.
- Local
Failure Policy - The sibling behavior selected after one local child fails.
- Plan
Error - A flow graph that cannot be compiled into an executable plan.
- Step
Components - The executable kind and restart-relevant declaration of one step node.
Constants§
- MAX_
BRANCH_ STEPS - The maximum number of linear steps in one split branch.
- MAX_
OUTGOING_ TRANSITIONS - The maximum number of transitions leaving one node.
- MAX_
PARTITION_ WORKERS - The maximum number of concurrent local partition workers.
- MAX_
PATTERN_ BYTES - The maximum length of one exit pattern in UTF-8 bytes.
- MAX_
SPLIT_ BRANCHES - The maximum number of branches in one M4 split.