MemorySizedCache could be leaking memory.

Describe the bug

While looking at the code to try to understand why ~1.4GB of heap memory appears unaccounted for in my production setup, I discovered that MemorySizedCache doesn't seem to take into account the size of the key. This is particularly problematic for LeafSearchCache which uses the (large) SearchRequest as a cache key.

On my production environment, the partial_request cache is the default 64MB, but from the metrics, I observe ~1 million entries for 35MB (35B per entry, the cache is half full). By my estimate, the SearchRequest, which includes the query AST, should be ~1400B per entry (~1.4GB for all the keys), which matches the ~1.4GB of unaccounted heap memory in my production setup.

• The LeafSearchCache cache key is computed here.
• LeafSearchCache uses a MemorySizedCache with the default LRU implementation
• The LRU cache implementation doesn't take the key into account when putting an entry in the cache

Full disclaimer

I haven't been able to identify with certitude the root cause of my problem, this bug report is mostly based on my analysis of the code.

Steps to reproduce (if applicable)

I haven't been able to clearly reproduce/find a metric that point to the exact problem, but a unit test similar to this seems to pass, confirming my suspicion:

    #[test]
    fn test_key_size_is_not_accounted_for() {
        let cache = MemorySizedCache::<String>::from_config(
            &ByteSize::b(16).into(),
            &CACHE_METRICS_FOR_TESTS,
        );

        let long_key = "k".repeat(1_000);
        // The entry is stored even though key + value is ~1000 bytes, way above the 16 bytes capacity
        cache.put(long_key.clone(), OwnedBytes::new(&b"0123456789"[..]));
    }

Expected behavior

A partial request cache of size 64MB shouldn't need ~2GB of additional heap to store the keys.

Configuration:

quickwit version: 0.9.0 (x86_64-unknown-linux-gnu 2026-07-25T17:48:09Z cc420c3)