What causes "cache: insufficient space and no entries to evict" in gofiber/fiber?

Raise Config.MaxBytes so typical responses fit with headroom for churn.

cache: insufficient space and no entries to evict

Error message

cache: insufficient space and no entries to evict

What it means

Returned by middleware/cache when, under a MaxBytes budget, the cache has reserved space for a new response body but the eviction heap is empty and the body still does not fit. The middleware reserves bytes up front, evicts LRU entries to get under the limit, and if it runs out of evictable entries before fitting the new body it un-reserves and returns this inline error. It is a fresh errors.New value, not a package-level sentinel.

Solutions

Raise Config.MaxBytes so typical responses fit with headroom for churn.
Reduce the response body size being cached (compression, pagination) so it fits reliably.
Treat the error as transient: the response is still served to the client (it is not cached), so no user-facing fix is strictly required unless caching is load-bearing.
If the error is logged per-request and noisy, raise MaxBytes or filter it in your log pipeline.

Example fix

// before
cache.New(cache.Config{MaxBytes: 1 << 16}) // 64 KiB, too tight
// after
cache.New(cache.Config{MaxBytes: 1 << 22}) // 4 MiB headroom

Defensive patterns

Strategy: fallback

Try / catch

// cache internal error; callers usually see it via logs. Treat as soft:
// the response is still served uncached. Monitor frequency and raise MaxBytes if noisy.

Prevention

Size Config.MaxBytes to several times your largest cacheable response plus churn headroom.
Monitor cache error logs; a rising rate signals MaxBytes is too small for the workload.
Prefer fixing MaxBytes over suppressing the log, since uncached hot paths hurt latency.

When it happens

Trigger: Configuring cache with MaxBytes set small, then caching a response whose body is individually smaller than MaxBytes (so the early bail-out at the top is skipped) but larger than the free space left after the heap is drained. Concurrent inserts can drain the heap between the size pre-check and the eviction loop.

Common situations: Tight MaxBytes on a high-churn cache; a sudden large response after the cache filled with many small entries that were all just evicted; misjudging MaxBytes versus typical response sizes.

Related errors

AI-assisted analysis of gofiber/fiber@a105acad6c (2026-08-11). Data as JSON: /api/errors/f7b42bba9053962f. Report an issue: GitHub.

Appendix: source

Thrown at middleware/cache/cache.go:724

		if cfg.MaxBytes > 0 {
			mux.Lock()
			// Reserve space for the new entry first
			storedBytes += bodySize
			spaceReserved = true

			// Now evict entries until we're under the limit
			var keysToRemove []string
			var sizesToRemove []uint
			var candidates []evictionCandidate

			for storedBytes > cfg.MaxBytes {
				if heap.Len() == 0 {
					// Can't evict more, unreserve space and fail
					storedBytes -= bodySize
					// Set spaceReserved to false so the deferred cleanup does not unreserve again
					spaceReserved = false
					mux.Unlock()
					return errors.New("cache: insufficient space and no entries to evict")
				}
				next := heap.entries[0]
				keyToRemove, size := heap.removeFirst()
				keysToRemove = append(keysToRemove, keyToRemove)
				sizesToRemove = append(sizesToRemove, size)
				candidates = append(candidates, evictionCandidate{
					key:  keyToRemove,
					size: size,
					exp:  next.exp,
				})
				storedBytes -= size
			}
			mux.Unlock()

			// Perform deletions outside the lock
			if len(keysToRemove) > 0 {
				for i, keyToRemove := range keysToRemove {
					delErr := deleteKey(reqCtx, keyToRemove)

View on GitHub (pinned to a105acad6c)