Struct SequentialCheckpoint 

#[non_exhaustive]
pub struct SequentialCheckpoint {
    pub schema_version: u32,
    pub next_chunk_index: u64,
    pub bytes_read: u64,
    pub patch_name: Option<String>,
    pub patch_size: Option<u64>,
    pub in_flight: Option<InFlightAddFile>,
}

Sequential-apply checkpoint payload.

Captures “how far into the patch stream the driver has gotten” using two independent measures so a resume can pick the right one:

• next_chunk_index — the zero-based index of the next chunk the driver is about to apply. Equal to the count of chunks that have been fully applied.
• bytes_read — the cumulative byte offset within the patch stream the driver has read up to. Equivalent to the crate::ChunkEvent::bytes_read field at the same emission point.

in_flight is Some only between DEFLATE block boundaries inside an SqpkFile::AddFile; per-chunk emissions carry None. Resuming a sequential apply that crashed mid-AddFile picks up at in_flight.block_idx, seeking to in_flight.bytes_into_target within the target file before resuming the chunk’s block loop.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

schema_version: u32

Layout version of this checkpoint struct. See Self::CURRENT_SCHEMA_VERSION.

next_chunk_index: u64

Index of the next chunk to apply. Equal to the number of chunks that have been fully applied as of this checkpoint.

bytes_read: u64

Cumulative byte offset within the patch stream the driver has read.

Informational metadata. Resume is positional on next_chunk_index, not on this counter: the fast-forward re-parses next_chunk_index chunks and surfaces a warn! (but does not error) if the resulting bytes_read differs from the value recorded here.

patch_name: Option<String>

Identifier the driver was told to associate with the patch source — typically the patch filename. None when no identifier was supplied via crate::ZiPatchReader::with_patch_name. Used at resume time to detect a checkpoint that was persisted for a different patch.

patch_size: Option<u64>

Total byte length of the patch stream, when the driver could measure it (i.e. the underlying reader is std::io::Seek). None for the sequential apply_to path which only requires std::io::Read; populated by resume_apply_to. Used together with patch_name to detect a checkpoint persisted for a patch that has since been replaced.

None means the recording driver did not know the size (e.g. checkpoints captured via crate::ZiPatchReader::apply_to with a Read-only source); the resume path will not use it for stale detection in that case — the patch_name check alone governs. Stale-detection mismatch only fires when both the checkpoint and the resume side carry a Some and the two values disagree.

in_flight: Option<InFlightAddFile>

Mid-chunk state for an in-flight crate::chunk::sqpk::SqpkFile AddFile. Present only at per-block emissions; None at per-chunk emissions.

Implementations

impl SequentialCheckpoint

pub const CURRENT_SCHEMA_VERSION: u32 = 1

Current schema-version constant for SequentialCheckpoint.

pub fn new( next_chunk_index: u64, bytes_read: u64, patch_name: Option<String>, patch_size: Option<u64>, in_flight: Option<InFlightAddFile>, ) -> Self

Construct a SequentialCheckpoint with the given fields.

Exists because the struct is #[non_exhaustive], which forbids external code from using the struct-literal syntax. Consumers hand-rolling a synthetic checkpoint (typically in tests, or when migrating a persisted checkpoint from an older schema) construct one via this method instead.

Notes

The constructor is intentionally permissive: it accepts any combination of fields, including pairings the apply driver itself would never emit. Resume re-validates against the patch stream and the on-disk state before honouring a checkpoint, so contradictory inputs are detected at resume time and either trigger a warn-and-restart (stale-detection paths) or surface as a typed error — never silent corruption.

pub fn with_in_flight(self, in_flight: Option<InFlightAddFile>) -> Self

Return a clone of self with in_flight overwritten.

Convenience for resume tests / persistence-layer code that needs to splice an in-flight payload into an otherwise-untouched chunk-boundary checkpoint without re-naming every field.

Notes

Like Self::new, this is permissive — any InFlightAddFile payload is accepted regardless of whether it pairs sensibly with the chunk index or byte offset on self. Resume re-validates before acting on the in-flight state, so a mismatch surfaces as a warn-and-restart rather than silent corruption.

Trait Implementations

impl Clone for SequentialCheckpoint

fn clone(&self) -> SequentialCheckpoint

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for SequentialCheckpoint

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

Formats the value using the given formatter.

impl PartialEq for SequentialCheckpoint

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

Tests for self and other values to be equal, and is used by ==.

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

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Eq for SequentialCheckpoint

impl StructuralPartialEq for SequentialCheckpoint