The subscription content cache (subscriptionCache table, managed by StateCache) has no size- or age-based eviction. New content is inserted on every subscription refresh (StateCache.CacheContent, deduped by Url) but never pruned. The only cleanup paths are Clear() (wipe everything) and ClearToday() (remove today's items to force a refresh).
As a result the cache accumulates content from every channel ever seen in the subscription feeds, including channels the user has since unsubscribed from, and grows without bound. On a real profile it reached 58,894 rows / 118 MB, spanning 702 distinct channels while the account only has 92 subscriptions.
Note: ClearToday() is also effectively a no-op for most feed content, because feed items commonly have DateTime = 0 (platforms report relative dates, so the plugin serializes unix 0, which UnixSupportedDateTimeConverter maps to 1970-01-01). But even if it worked, it was never meant to bound the cache size.
Impact: unbounded disk growth over time. It also caused very slow startup on large caches, but that part is the missing column indexes, addressed separately in #971.
Not proposing a specific behavior here, just reporting the growth. Possible directions for maintainers: prune content for channels no longer subscribed; cap items per channel; or a global size cap with insertion-order eviction.
The subscription content cache (
subscriptionCachetable, managed byStateCache) has no size- or age-based eviction. New content is inserted on every subscription refresh (StateCache.CacheContent, deduped byUrl) but never pruned. The only cleanup paths areClear()(wipe everything) andClearToday()(remove today's items to force a refresh).As a result the cache accumulates content from every channel ever seen in the subscription feeds, including channels the user has since unsubscribed from, and grows without bound. On a real profile it reached 58,894 rows / 118 MB, spanning 702 distinct channels while the account only has 92 subscriptions.
Note:
ClearToday()is also effectively a no-op for most feed content, because feed items commonly haveDateTime = 0(platforms report relative dates, so the plugin serializes unix0, whichUnixSupportedDateTimeConvertermaps to1970-01-01). But even if it worked, it was never meant to bound the cache size.Impact: unbounded disk growth over time. It also caused very slow startup on large caches, but that part is the missing column indexes, addressed separately in #971.
Not proposing a specific behavior here, just reporting the growth. Possible directions for maintainers: prune content for channels no longer subscribed; cap items per channel; or a global size cap with insertion-order eviction.