Progressively less disk space when combining nocache tags and cache tags

[tom-m-clarity-growth]

Bug description

I have implemented a caching strategy using a combination of the app cache for items that are updated intermittently using the cache tag with a key. I then wrapped them in a nocache tag to keep them dynamic so i could static cache the rest of the page:

{{ nocache }}
    {{ cache key="navigation }}
        {{ nav select="url|title" include_home="false" depth="3" }}
            ...
        {{ /nav }}
    {{ /cache }}
{{ /nocache }}

with an event listener set up:

public function boot()
{
    parent::boot();

    // Main Navigation Invalidator
    Event::listen(function (NavTreeSaved $event) {
        if ($event->tree->handle() === 'pages') {
            Cache::forget('navigation');
        }
    });
}

The issue is that the disk space on the sites this is used on is steadily climbing to its limit without tending toward a maximum which would suggest invalidated cache's aren't being deleted once invalidated but instead replaced by new cache data that is referenced in place of the original.

I'm relatively new to the inner workings of statamic so I was wondering what was going wrong. I'm looking into an alternative solution suggested here in the meantime, but it would be useful to know if this is a bug as it would be nice if it could be addressed to prevent any requirement for me to change these implementations. Alternatively if it isn't a bug, it would be useful if a warning and/or explanation could be added to the documentation to prevent others making the same mistake as me.

How to reproduce

Using a half static caching strategy, wrap a cache tag with a nocache tag in a template to allow for cached semi-dynamic content within a static page:

{{ nocache }}
    {{ cache key="navigation }}
        {{ nav select="url|title" include_home="false" depth="3" }}
            ...
        {{ /nav }}
    {{ /cache }}
{{ /nocache }}

with an event listener set up in app/Providers/EventServiceProvider.php:

public function boot()
{
    parent::boot();

    // Main Navigation Invalidator
    Event::listen(function (NavTreeSaved $event) {
        if ($event->tree->handle() === 'pages') {
            Cache::forget('navigation');
        }
    });
}

Logs

No response

Environment

app env = local and production
static caching = half

Installation

Other (please explain)

Additional details

Installed on our own internal starter kit

[JohnathonKoster]

Hey there! Which version of Statamic are you running on this site?

Thanks!

[ryanmitchell]

If you are using the no cache tag I would recommend using the select="..." param to select the variables you need, otherwise it will create a new no cache region for every user on the site, which is why you're seeing progressively more usage.

Beyond that, you may want to look at an add-on we provide - https://statamic.com/addons/thoughtco/cache-tracker - which tracks what items are output on a page allowing the cache to be selectively cleared. It does what you are trying but without using no cache tags.

[tom-m-clarity-growth]

Which version of Statamic are you running on this site?

Statamic 4.58.2

[tom-m-clarity-growth]

If you are using the no cache tag I would recommend using the select="..." param to select the variables you need, otherwise it will create a new no cache region for every user on the site, which is why you're seeing progressively more usage.

Beyond that, you may want to look at an add-on we provide - https://statamic.com/addons/thoughtco/cache-tracker - which tracks what items are output on a page allowing the cache to be selectively cleared. It does what you are trying but without using no cache tags.

Thanks for the explanation!

I didn't see the documentation on select for nocache tags before, but thats super helpful.

As for the creation of an instance per user, this would explain the ever expanding cache. It may be worth a warning being added to the statamic docs to prevent others from creating the same issue for themselves.

Looks like your addon is the solution we were originally trying to achieve here anyway!