tts_cache grows without bound — no cap, no TTL, no eviction

[Ninthkitten]

Prerequisites

• I searched open issues and discussions and did not find an existing report of this bug.
• This is not a security vulnerability.
• I am running the latest code from the dev branch.

Install Method

Docker

Operating System

macOS (Apple Silicon), Docker Desktop

Steps to Reproduce

1. Enable TTS and use voice replies normally for a few hours.
2. Watch data/tts_cache.

Expected Behaviour

The cache has some bound — a size cap, a TTL, or an eviction pass.

Actual Behaviour

_put_cache in services/tts/tts_service.py writes forever. There is no cap, no TTL and no eviction anywhere in the module. Measured here: 201 MB / 968 files in 13 hours (~15 MB/h) under ordinary use. On a long-running instance it grows without limit until the disk does the limiting.

Additional Information

Fix running here:

• TTS_CACHE_MAX_MB cap; _put_cache calls an eviction pass that deletes oldest-first until the directory is under the cap.
• Eviction reads the directory, not a process-local index, so files written before a restart are still seen (see the sibling report about the search cache for why that distinction matters).
• _get_cached touches the file on a hit, so mtime means last used — real LRU rather than "oldest written".
• Only .wav/.mp3 are eligible; everything else is left alone.
• The whole pass is exception-wrapped: eviction must never be able to fail a synthesis.

Note for anyone measuring: du reports block-rounded sizes. Our first reading of "201M" was 198.9 MiB by byte count — worth knowing when setting a cap near the observed value.

Are you willing to submit a fix?

Yes — the fix described above is running in production here and I can open a PR.