<feed xmlns='http://www.w3.org/2005/Atom'>
<title>meshbay.git/packages/meshbay-node/tests/test_media_cache_eviction.py, branch 0.14</title>
<subtitle>MeshBay — read-only public mirror</subtitle>
<id>https://git.meshbay.org/meshbay.git/atom?h=0.14</id>
<link rel='self' href='https://git.meshbay.org/meshbay.git/atom?h=0.14'/>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/'/>
<updated>2026-09-08T11:21:02Z</updated>
<entry>
<title>feat(node): cap the media cache and evict least-recently-used entries</title>
<updated>2026-09-08T11:21:02Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-09-08T11:21:02Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=db69d0e351b59f6fd9335995c7994bd2933f668a'/>
<id>urn:sha1:db69d0e351b59f6fd9335995c7994bd2933f668a</id>
<content type='text'>
`thumbs` holds every generated thumbnail, every TMDB poster and backdrop, every
Cover Art Archive image and every cached audio transcode. Rows were removed only
when their source file left every group's index (`prune_file`), so a library
that merely changes over years grew this database with nothing to bound it.
Nothing in it is precious — every row is keyed off a value the node can
re-derive — which is what makes eviction the right answer rather than a bigger
disk.

512 MB, evicted on write (a cache only grows when written to; a timer is one
more thing to own and get wrong). `used_at` is marked on every read, including
the lookup by synthetic id that `_fetch_and_cache_poster` makes on every visit
to a poster grid — without that, the images shown most often would be the
coldest rows in the table. A single blob larger than the cap does not empty the
table for nothing.

The migration is the part that touches deployed nodes. `CREATE TABLE IF NOT
EXISTS` adds missing tables and never missing columns, so `used_at` would have
reached a fresh test database and never a real one. `_migrate()` does the
ALTER TABLE and seeds existing rows with "now" rather than 0 — otherwise the
first write after an upgrade evicts the whole cache, a correct-but-hostile
reading of "least recently used" for rows whose age nothing recorded.

The index on that column lives in `_migrate()`, not in `_SCHEMA`: run from the
schema script it executes before the ALTER on an existing database and fails,
which would have been every deployed node refusing to open its cache on the
first start after upgrading. Found by the migration test.

Verified against a real node's database, rebuilt into its pre-migration shape:
rows preserved, column present, seeded, index created, reopening harmless.

Co-Authored-By: Claude Opus 5 &lt;noreply@anthropic.com&gt;
Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST
</content>
</entry>
</feed>
