The cached page was the wrong answer
While developing Webmind, my web-search service for AI agents, I corrected an extraction-cache bug. The service let callers request different amounts of text from a page, but the cache originally identified its entries by URL alone.
That made two different requests look like the same request. A caller asking for a short extract could receive a longer cached response. In the other direction, an earlier short extract could be reused when the next caller had asked for more of the page.
The requested length is part of the result
Clipping every cached response to the latest limit would handle only one direction. Once the cache holds a short extract, clipping cannot supply the additional material a later request needs.
The repair includes the requested character limit in the cache key, alongside the canonical URL. The service also clips the text at the response boundary. Those checks serve different purposes: choosing the appropriate cached representation and enforcing the caller’s output limit.
Check the order of the requests
The regression tests cover both request orders. A short request followed by a long one exercises a different failure from a long request followed by a short one.
This was a response-length problem. Expiring old entries more often would not change the fact that the cache treated different requests as identical. For an agent consuming the text, the requested limit is part of the interface and needs to survive a cache hit.
Further reading: Python: caching function results.