Context
read_hash_encrypt (crates/driven-core/src/executor.rs, ~line 6582) buffers its whole input into memory by design. Its "must never be called on an arbitrary-size file" invariant is currently doc-comment-only, with no runtime enforcement.
The 2026-08-14 OOM incident (fixed in #279) was exactly a caller violating this invariant: the startup reconcile path buffered an 88.6 GB file into RAM when resuming an interrupted upload.
Ask
Add a max-size parameter (or a debug assertion) to read_hash_encrypt that errors past a cap, so the invariant can no longer be silently violated by a future caller.
Today's sole unbounded-risk callers are already gated (inline_upload < PIPELINE_THRESHOLD, planner-capped bundles), so this is a defense-in-depth hardening measure rather than a fix for a currently-reachable bug.
Care needed
The cap must not change the existing grew-mid-read (ChangedDuringUpload) error semantics - a file that grows past the cap mid-read should still surface as the existing error type, not a new generic "too big" error, where that distinction matters to callers.
Reference
PR #279 (fix(core): stream the resumable-upload resume instead of buffering the whole file) - this was one of the deferred hardening items from its multi-agent review.
Context
read_hash_encrypt(crates/driven-core/src/executor.rs, ~line 6582) buffers its whole input into memory by design. Its "must never be called on an arbitrary-size file" invariant is currently doc-comment-only, with no runtime enforcement.The 2026-08-14 OOM incident (fixed in #279) was exactly a caller violating this invariant: the startup reconcile path buffered an 88.6 GB file into RAM when resuming an interrupted upload.
Ask
Add a max-size parameter (or a debug assertion) to
read_hash_encryptthat errors past a cap, so the invariant can no longer be silently violated by a future caller.Today's sole unbounded-risk callers are already gated (
inline_upload < PIPELINE_THRESHOLD, planner-capped bundles), so this is a defense-in-depth hardening measure rather than a fix for a currently-reachable bug.Care needed
The cap must not change the existing grew-mid-read (
ChangedDuringUpload) error semantics - a file that grows past the cap mid-read should still surface as the existing error type, not a new generic "too big" error, where that distinction matters to callers.Reference
PR #279 (fix(core): stream the resumable-upload resume instead of buffering the whole file) - this was one of the deferred hardening items from its multi-agent review.