Skip to content

feat(index): enforce opt-in storage resource limits - #1725

Open
liuchong wants to merge 3 commits into
DeusData:mainfrom
liuchong:feat/index-resource-storage
Open

feat(index): enforce opt-in storage resource limits#1725
liuchong wants to merge 3 commits into
DeusData:mainfrom
liuchong:feat/index-resource-storage

Conversation

@liuchong

@liuchong liuchong commented Aug 19, 2026

Copy link
Copy Markdown

Stacked on #1724. A fork PR must target a branch in this repository, so the diff below also contains the two commits under it. The new work here is the last commit, bd6ea29d. Once #1724 merges, this diff shrinks to that one commit on its own.

Related to #1347.

Problem

An index that fits in memory and finishes in time can still fill the disk. Publication needs room for the staging artifacts and the final database at the same time, and running out of space during publication is the one failure that can cost a working index.

What this changes

Two opt-in limits, both defaulting to off:

Key Meaning
index_cache_max_mb Maximum total size of the cache directory
index_min_free_disk_mb Minimum free space that must remain on the cache volume

They are measured before staging and again before publication, because the interesting moment is the one where both copies exist.

Three internal ceilings — final database, staging artifacts, task temporary directory — are added alongside them. They deliberately have no public keys: they are only meaningful as part of one composed decision about how much room a publication may take, which no single operator-facing key can express.

Crossing any of them fails the attempt before the old database is touched. Atomic publication is unchanged and the previous index keeps serving.

Two details worth review attention:

  • Staging cleanup is scoped by a private per-task token, so a worker removes only the artifacts it created. Cleanup that matched on path alone could delete a concurrent run's staging files.
  • An old database is treated as replaceable only after an integrity verdict distinguishes genuine corruption from a transient SQLITE_BUSY. Treating busy as corrupt would discard a healthy index.

Probes fail closed: an enabled measurement that cannot be completed fails the attempt rather than being assumed to pass.

Testing

make -f Makefile.cbm test and make -f Makefile.cbm lint-ci on macOS. New coverage: directory-size and free-space measurement on each platform path, admission at both checkpoints, task-token-scoped cleanup leaving unrelated cache files intact, preservation of the old index on rejection, and the busy-versus-corrupt integrity verdict.

Stack

  1. feat(index): add opt-in discovery resource limits #1723 — discovery limits
  2. feat(index): add worker resource watchdogs #1724 — worker watchdogs
  3. this PR — storage limits
  4. feat(index): add opt-in index resource profiles #1726 — resource profiles
  5. feat(index): record and report the latest index attempt #1727 — attempt record and freshness
  6. feat(mcp): warn on answers served from a failed rebuild #1728 — stale-index warning on answers

@github-actions

Copy link
Copy Markdown

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

  • It will not be closed for inactivity. No stale bot touches pull requests here.
  • It may still sit a while before a human reads it. That is on us, not on you.
  • Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

  • Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
  • Get CI green, or say which failures you believe are pre-existing.
  • Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
  • Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Indexing accepts whatever a repository contains. A tree carrying a vendored
monorepo, a generated dump, or a runaway build directory is discovered in
full, and the first sign of trouble is a host under memory pressure with
nothing that attributes it to indexing.

Add two opt-in limits evaluated during discovery against accepted source
files only: index_max_files and index_max_source_mb. Both default to off, so
nothing changes until an operator sets one. Crossing a limit fails the whole
attempt with a structured resource_limit_exceeded result naming the resource,
the observed value and the limit; no partial graph is published, and an
existing serving index keeps answering.

Limits are read from the CLI-managed _config.db and are not MCP request
arguments. A supervised parent replaces any caller-supplied policy before
spawning its worker, and the worker rejects a missing or incomplete contract,
so the CLI, the daemon and the supervised worker all enforce the same
decision.

The two shell regressions that hand-roll the supervisor's worker argv carry
that contract as well. Without it the worker exits before either guard can
observe anything, and the guard would go quietly vacuous.

Signed-off-by: 刘冲 <mail@liuchong.dev>
Discovery limits bound what indexing accepts, not what it then costs. A
repository well inside those bounds can still exhaust the host through parser
memory, or simply never finish, and a supervised worker that hangs leaves the
parent waiting with nothing to report.

Add index_max_rss_mb and index_max_duration_seconds, enforced by the parent
against the worker process tree rather than the worker process alone, so a
runaway child cannot hide behind a small parent. Resident memory is sampled
through the platform interface on macOS, Linux and Windows. Crossing a limit
terminates the tree and yields one trusted, structured terminal result that
attributes the failure to the resource that caused it.

Both limits default to off. A measurement that cannot be taken fails the
attempt instead of passing it: a watchdog that quietly stops watching is
worse than no watchdog at all.

The shell fixture that stands in for the supervisor names the two new keys.
The worker accepts only a policy that spells out every key it knows, which is
what keeps a stale supervisor from starting a worker it cannot bound.

Signed-off-by: 刘冲 <mail@liuchong.dev>
An index that fits in memory and finishes in time can still fill the disk.
Publication needs room for the staging artifacts and the final database at
the same time, and running out of space during publication is the one
failure that can cost a working index.

Add index_cache_max_mb and index_min_free_disk_mb, measured before staging
and again before publication, together with internal ceilings on the final
database, the staging artifacts and the task temporary directory. Those three
have no public keys because they are only meaningful as part of one composed
decision. Crossing any of them fails the attempt before the old database is
touched, so atomic publication is unchanged and the previous index keeps
serving.

Staging cleanup is scoped by a private per-task token, so a worker removes
only the artifacts it created and never a concurrent run's. An old database
is treated as replaceable only after an integrity verdict distinguishes real
corruption from a transient busy error. A probe that cannot complete fails
closed. Both public keys default to off.

The shell fixture that stands in for the supervisor names them too, so the
worker still recognises the policy it is handed.

Signed-off-by: 刘冲 <mail@liuchong.dev>
@liuchong
liuchong force-pushed the feat/index-resource-storage branch from bd6ea29 to f14844b Compare August 19, 2026 14:44
@liuchong liuchong closed this Aug 20, 2026
@liuchong liuchong reopened this Aug 20, 2026
@liuchong
liuchong marked this pull request as ready for review August 20, 2026 03:38
@liuchong
liuchong requested a review from DeusData as a code owner August 20, 2026 03:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant