Repository navigation
fix(retention): bound active pointer reads in storage reports - #4809
Open
ScriptedAlchemy wants to merge 7 commits into
Open
ScriptedAlchemy wants to merge 7 commits into
ScriptedAlchemy wants to merge 7 commits into
Conversation
Reject oversized or nonregular publication pointers before allocation, including metadata-only retirement plans used by storage reports. Exercise oversized valid JSON, sparse large files, symlinks, FIFOs, and a 70-seal plus 15 GiB code-index project report. Refs #4616
|
The oversized-pointer regression now verifies the directory inventory budget is untouched on refusal. Align the sparse report fixture with workspace Rust formatting conventions. Refs #4616
The sparse 70-generation/15 GiB code-index regression now exercises both the targeted retention-planning report and the full offline storage-report entry point with complete size-coverage assertions. Refs #4616
The large-store reporting regression invoked a non-existent StorageReport method. Assert the populated FullProfileSizeV1 field instead so the native Bazel test compiles and checks complete profile coverage. Refs #4616
Apply the three exact Rust 2024 formatter corrections reported by Repository gates for the bounded pointer and storage-report regressions. Keep assertions and production logic unchanged. Refs #4616
This was referenced Nov 8, 2026
Repair three hosted automation_runner_test failures by supplying the configured executable identity required by the production prefilter. Use the same identity for the prefilter and retained runner, preserving manual-schedule, exact-ledger, live-lock and lock-race assertions. Add a production-prefilter regression for unconfigured refusal, deduplication and same-occurrence recovery after binding, with zero backend calls and no effectful terminal. Do not relax backend admission, change timeouts, or alter the graph publication changes. Refs #4532
This was referenced Nov 9, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause
Refs #4616 — partial OOM-safety repair, not a sealed-generation collector or full issue closure.
The code-generation retention planner reads
active-code-generation-v1.jsonwith an unboundedstd::fs::read. Although its writer caps the durable pointer to 512 KiB, malformed/stale/foreign files need not obey that invariant. Both the daemon's storage-report planning and other metadata-only retention paths still deserialize this pointer before their entry/digest budgets protect the rest of the traversal. A sparse multi-GiB pointer could therefore force an unbounded allocation or block the worker if substituted with a FIFO.Focused fix
tracedecay-private-fs::framed_log::read_boundedfile authority already depended upon by this crate: one held no-follow, nonblocking regular-file read capped atMAX_DURABLE_PUBLICATION_POINTER_BYTES_V1, with length verification before allocation and after reading.build_storage_reportentry point with complete profile/store coverage assertions. No multi-GiB payload is allocated or copied by the test.Verification and boundaries
Initial source commit:
23f65556a9c3e81e2e6f0bb1d78112cc596e7c64; focused assertion/format follow-upf20bf8b67db5736c4a6697c52299200d2dfa21ad; full-report coverage69e4e17f89f199afb75223c30901e53ce2b0be8e; parentmaster91c72aba7750a398dd28e83d64bf0c6d6fef4172. Published through expected-old-head,force=falsefast-forward. Only two issue-specific source/test paths changed; this branch does not derive from or move the mixed held #4776 work.Not yet a Bazel/native test pass: run
bazel test //crates/tracedecay-code-index-retention:unit_test //crates/tracedecay-maintenance:unit_test --test_output=errors; check a nonzero regression count and native macOS CI. Do not use Cargo. Root/nested AGENTS.md rules and active peer ownership respected.This covers one concrete unbounded allocation in the report/retention journey and now exercises the full offline report collector on the large sparse store. Until actual Bazel/native runs prove it, it does not close OOM acceptance, and it does not prove N>3 sealed retirement, verified deletion under owner/root substitution or sustained-writer progress. Keep #4616 open until all acceptance criteria pass on
master. Mixed draft #4776 and Kev/decision-model work remain excluded from merging; release #4763 and production/infra untouched.