Module incremental 

Incremental projection rebuild and invalidation.

On startup, instead of replaying the entire event log, we read the projection cursor (byte offset + last event hash) from projection_meta and replay only events after that point.

Safety checks

Before doing an incremental apply, several invariants are verified:

1. Schema version — the DB schema version must match migrations::LATEST_SCHEMA_VERSION. A mismatch means the code has been upgraded and a full rebuild is needed.

2. Cursor hash found — the last_event_hash stored in the cursor must appear in the shard content at the expected byte offset. If the hash cannot be found the shard was modified (e.g. deleted/rotated) and incremental replay is unsafe.

3. Sealed shard manifest integrity — for every sealed shard that has a .manifest file, the recorded byte_len must match the actual file size. A mismatch indicates shard corruption or tampering.

4. Projection tracking table — the projected_events table must exist. If it doesn’t, we can’t deduplicate and must rebuild.

When any check fails, incremental_apply falls back to a full rebuild automatically, returning the reason in ApplyReport::full_rebuild_reason.

Structs

ApplyReport

Report from an incremental apply operation.

EventHash

Identifies the last event that was successfully applied to the projection. Stored in the projection_meta table in SQLite.

Functions

check_incremental_safety

Check if incremental apply is safe or if full rebuild is needed.

incremental_apply

Apply only events newer than the high-water mark to the projection.

read_hwm

Read the current high-water mark from the SQLite metadata table. Returns None if no events have been applied (fresh DB).

write_hwm

Write the high-water mark after successful apply.