mirror of
https://github.com/garrytan/gstack.git
synced 2026-10-31 14:06:50 +01:00
Garry Tanandcapy-ai[bot]
52eec18c63
* fix(cso): give snapshot.json its own 16 MiB cap and actionable capacity errors /cso refused any repository with more than about 3,100 tracked files before an audit started: the snapshot manifest was pretty-printed and both its writer and every reader capped it at the shared 1 MiB private-state limit (#3068, manifest half of #2993). - snapshot.json is written compactly and capped by SNAPSHOT_MANIFEST_LIMIT (16 MiB), a constant local to the snapshot module. - readJson takes a per-artifact cap; readSnapshotManifest is the only reader of snapshot.json and passes the snapshot cap through recovery and the private-file size check. MAX_STATE_FILE and MAX_OUTPUT stay 1 MiB. - The manifest-cap and 64 MiB source-cap errors name the bound cap, the measured value, what counts toward it, the next step and #2993. A single file that would cross 64 MiB now hits the same message before it is read. - Older pretty-printed manifests still load (recheck, inspect). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(cso): bound per-entry report and evidence lists with omitted counts Lifting the manifest cap alone moved the failure into the audit: report.json listed one transformation per transformed entry plus one coverage gap or exclusion per omitted entry (1.97 MB for 5,000 nested paths), and sensitive-evidence.json grew per scanner hit (1.68 MB), both under the 1 MiB private-state cap that saveReport and the start stdout share. - boundedList (state.ts) keeps the leading entries that fit a byte budget, measured as the pretty-printed JSON they add at their nesting depth, and ends the list with one summary carrying the omitted count. - report.json snapshot lists share one 256 KiB budget (gaps 128 KiB, transformations 96 KiB, exclusions 32 KiB); coverage counts and status are computed before trimming, so they stay exact. - sensitive-evidence.json keeps 512 KiB of per-file evidence plus an omitted-count record. - Snapshot coverage and publicSnapshotPath no longer scan the whole manifest per entry. Test: 5,000 long nested paths, mostly excluded or withheld, 999 files with scanner hits, driven through start, inspect, submit, finish and recheck. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(cso): admit Git path listings above 1 MiB during snapshot capture With the manifest cap lifted, the next file-count wall was the shared 1 MiB process-output cap on Git's path listings: ls-files/ls-tree --name-only failed at roughly 15-20k files (23,749-file grafana/grafana fails there) and the comparison-base ls-tree near 8-10k. runProcess lets raw callers, whose output is never printed or persisted, opt in to up to 16 MiB; git() forwards an optional cap, and the four snapshot listings pass SNAPSHOT_MANIFEST_LIMIT. Every other caller keeps the MAX_OUTPUT clamp. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * docs(cso): explain the capacity refusals and file the follow-ups docs/troubleshooting.md#cso-capacity covers the snapshot-list cap, the 64 MiB source cap and the tracked-symlink refusal. TODOS.md records the symlink design call, the #2993 aggregate cap, the full-manifest inspect output and repair-bundle transformations. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * chore(release): v1.91.42.0 /cso lifts its file-count ceiling Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --------- Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>