FileSystemCache files still persist even after expiration?

[stevenqzhang]

It seems like with a FileSystemCache, expired caches are still perisisted on disk unless the cache key is overwritten by a fresher value?

is this by design? or would it be a enhancement to autodelete expired cache entries?

Took a cursory glance at https://github.com/mistval/node-fetch-cache/blob/master/src/classes/caching/file_system_cache.ts#L23 and it seems to corroborate with my experience

[mistval]

Hi,

Yes you're right, and I think it would be an enhancement to autodelete expired cache entries so they don't hang around taking up disk space.

It would have to be done in a way that works across process restarts and multiple processes, so it couldn't just be a setTimeout() (like it is in MemoryCache). Perhaps a cache entry that contains an array of expiring entries and their expiration time, and poll that, although that array could become large and inefficient to parse into memory. If done that way, it might have to be optional behavior.

It might make sense to just have it be a feature of a new SQLiteCache or such, where the storage format can support efficiently querying for expired entries. Not sure if there's a good way to do that with cacache which is the backing store for FileSystemCache.

[TimDaub]

Actually this is highly problematic if you're running this package in prod and are not aware of this. I've had several minute/hour long down times because my disk was full and because this package isn't deleting even though TTL is set...

[mistval]

Thanks for raising that @TimDaub . I just pushed a v5.1.0 with a warning in the README about that, and a .clear() function you can call on a FileSystemCache instance to delete the whole cache from disk. It's a crude solution but that's probably about the best we can do with the cacache backing store. I'd still like to implement a SQLite cache which would better support active TTL cache ejection.