We have the same problem using Redis.

I have the same problem, with the latest version of Moodle 5.0+ (Build: 20250516)
and the latest version of the plugin qtype_coderunner: 2025052100 and qbehaviour_adaptive_adapted_for_coderunner: 2025012500

Thank you.

Hi everyone,

Thanks for raising the issues you're experiencing with the Coderunner grading cache — and sorry for the trouble it's causing.

To clarify the current situation:

• The grading cache does not currently support Redis as a cache store. This is primarily because Redis isn't well-suited for the grading cache's intended use case — storing results for extended periods (e.g., weeks), which can lead to memory pressure and potential crashes if default Redis settings are used.

• There's a bug in the scheduled task that manages the grading cache: it runs regardless of whether the cache is enabled and assumes a file-based cache is in use.

It sounds like many of you have already found the most reliable workaround for now:

• Disable the grading cache, and
• Turn off the scheduled task associated with it.

Alternatively, if you'd like to continue using the grading cache, you can switch to a file-based cache store. This allows the scheduled task to function as intended and helps manage old entries. However, Moodle doesn’t make it easy to change the cache store for a specific component without affecting the default application cache. If you manage to configure this successfully, please do share how you did it!

I’m actively working on improving compatibility with Redis, but it’s a tricky fit due to the nature of the grading cache. I’m also updating the cache cleaner logic, though progress has been slowed by changes in Moodle 5.0 — particularly around the question bank system — and the inherent complexity of Moodle’s caching framework.

Please feel free to email/post if you have any further questions/concerns/suggestions.

Cheers,
Paul

We have the same issue using Moodle 4.5, the latest version of the plugin qtype_coderunner: 2025050400 and qbehaviour_adaptive_adapted_for_coderunner: 2025012500 and Redis as cache configured.

Is there some reason we can't just use the TTL feature when defining this cache?

Hi Tim,

The problem with using the TTL setting for caches with a file store back-end is that the file stores don't ever delete old cache entries. File stores enforce the TTL on read by simply ignoring entries that are too old. But, those entries stay on disk forever.

The cache cleaner task is designed to run periodically and delete old cache entries (which are simply files on disk). This is similar to the ttl.php task that Redis has for removing old entries. Unfortunately file stores don't have any clean-up mechanism so I needed to write my own to ensure the cache doesn't use up too much disk space.

But, you are right, it would still be nicer to store the TTL setting in the normal place. I initially used a Coderunner setting instead because I thought the TTL setting in the caches.php file could only be updated by doing a Coderunner version bump. I have now found how to get changes in the caches file to take effect, ie, admin->plugins->cache admin->Rescan definitions - which isn't that easy to find! In my next update, I aim to update the Coderunner cache to use the normal TTL setting as set in the caches.php file and to only run the cleanup on file stores (the Redis cleanup is currently running every hour by default so it can do it's own cleanup).

Redis isn't ideal for the Coderunner cache as Redis runs in memory and entries aren't intended to hang around for long. I would assume the ttl for Redis caches is set to something in the order of minutes or hours, rather than the default two weeks that we use for the Coderunner grading cache. Entries in the grading cache need to be kept for a while to make them useful, eg, you might want to regrade an assignment or exam a few days after it closes to tweak the marking on some of the questions.

Our Coderunner caches can run into tens or hundreds of GB if left alone which would certainly blow the Redis memory limit with long TTL's (if Redis isn't setup carefully, eg, the default for Redis seems to be to just break or stop caching when memory is full, rather than cycling out old entries).

Therefore, once I get the updates in place to deal with Moodle 5 - which is proving to be quite painful. I'll be adding in the recommendation that the grade cache be used with file stores and that anyone who wants to try their luck with a Redis store needs to be aware that longer TTL's will put pressure on memory and therefore the Redis store needs to be setup to deal with memory filling up!

I hope this all makes sense. Feel free come back to me with any further questions or suggestions. The Moodle cache system is way more complex than it first seems, so any guidance will be much appreciated!

Cheers,
Paul

Thanks for explaining. Makes sense.

We're seeing this issue too with redis caching. Thanks for the detailed explanation! I'm not sure it's completely accurate though.

Redis isn't ideal for the Coderunner cache as Redis runs in memory and entries aren't intended to hang around for long.

This is only partially true. Redis can run this way, without any persistence (similarly to memcached), but it can also be configured to persist data indefinitely. The Moodle cachestore_redis plugin advertises that it supports "data guarantee" though, so anyone who has redis configured without persistence basically has a misconfigured cache. Unfortunately I don't think that's explicitly documented in the redis cache store docs.

Would it maybe be worth adding 'requiredataguarantee' => true to the grading cache definition to ensure that it it will only use a cache store that does guarantee the data will persist indefinitely? (I realise this doesn't fix anything where people have redis configured to behave like memcached but I'm not sure that's something that the plugin should need to work around.)