Invalidation logic for caching of MB search API responses

[arsinclair]

I know cache invalidation is a hard problem 🥲. But, it's an annoying one.

When augmenting a musicbrainz release with a barcode and then trying to search for that barcode in Harmony, it returns

MusicBrainz: API returned no results: https://musicbrainz.org/ws/2/release?query=barcode%3A853567576415&fmt=json

At first the MB API returns {"created":"2026-05-10T02:25:10.167Z","count":0,"offset":0,"releases":[]}, however within minutes MusicBrainz API starts to return the correct data. Harmony in turn keeps thinking that the data doesn't change because it had cached that request somewhere and for hours there's no way to process a release.

There needs to be some kind of invalidation mechanism: manual button (force refresh), a background query to MusicBrainz with 304 not modified response, a very small expiration date on caches for the releases imported within minutes/hours from the current datetime (as changes are expected, so it is not useful to cache), etc. Maybe folks have some better ideas.

[kellnerd]

I agree that caching in Harmony needs to be reworked. Currently every provider caches all requests for 24 hours (and permanently stores the cached data for permalinks, which also has become problematic with the increasing usage and requests like #107).
At some point I want to rework the caching logic to have two layers, the existing SnapStorage for permalinks and an additional, more traditional caching layer for everything else (which is not permanent and has a flexible invalidation strategy).

Copying a few relevant thoughts from #190:

All the outgoing API requests are currently cached indefinitely in order to guarantee that the permalinks in edit notes continue to work and provide evidence using the original/historic data that was used to import the release.
The SnapStorage cache therefore accumulates a lot of (mostly JSON) data (about 57GB in 18 months). While this is acceptable for the Release Lookup page which has a high probability of resulting in a MB import, it is wasteful for Release Actions already and almost pointless for most API requests that I would expect.

[...] Harmony needs a second, more traditional caching layer which discards data after a certain time (probably 24 hours). Only Release Lookup (or requests which explicitly need a permalink) should write to the permanent SnapStorage cache.
[Once they have been written] it is hard to impossible to get rid of the useless API snapshots.

See also #146 for the request to have an option to force-retry MB lookups.

[kellnerd]

Whenever I rework the caching, I can take the Cache web API into account this time. Deno 2.8 finally added the Cache.keys() method, whose absence was a showstopper for me the last time.