Part of #1350. Prevent a slow backend, small-entry workload or sustained admission from creating unbounded engine-owned work. Implement the minimum limits in #1360; this is not a general resource-management subsystem.
First-version blockers
- Define and enforce logical cache capacity, maximum entry/key size, admitted pending bytes and bounds on entry metadata and command counts. Byte limits alone must not permit unbounded tiny-entry or cleanup queues.
- Bound concurrent whole-object reads and serialization/write buffers. Limits may be derived from entry size and concurrency; a separate user-facing knob for every allocation is not required.
- Bound cleanup work and retained error records. When cleanup cannot finish, report it and hand residual objects to the namespace policy in #1355 rather than accumulating unlimited retries or bookkeeping.
- Reject cache admission when full or oversized without failing a successful source fetch. Release reservations after success, discard, failure and shutdown.
- Use focused large-entry, sustained-write and delayed read/write/delete checks to establish the advertised bounds and retry/refill behavior. State which counters are exact and which are estimates.
Logical capacity and engine-owned limits are not guarantees of total process RSS, filesystem usage or Redis memory. Document the boundary and any caller/backend quota responsibility.
Possible follow-ups — not blockers
Exact allocator/RSS accounting; exact physical usage across services; automatic backend quota management; adaptive backpressure; extensive memory profiling; and advanced observability. Add these only for demonstrated operational needs. Basic occupancy, pending-work and failure visibility should reuse existing counters where practical.
The prototype's queued payload and FIFO capacity checks are a starting point, not proof that all engine-owned work is bounded. Related: #1240, #848. Close this issue when the first-version limits and focused checks are complete.
Activity
0No activity yet.