There is a few other trackers related to this, eg MDL-73317, MDL-69977. Fundamentally the session is only writable under certain conditions and it could be readonly or it could have been closed early which is a good thing. The cache api on the other hand expects that it should always be available. When readonly sessions is enabled you must map the session cache store to something which isn't in the session for this reason but that is a workaround.

There are race condition bugs if we write the entire store rather than key by key if we are outside of a session lock.

Some ideas:

1) We somehow make the default session store things alongside the session in a way which can be written even if the session is closed. This seems difficult and probably unviable

2) We just deprecate it and the default store becomes something else.

3) while we cannot write to the session cache in all cases maybe we can do some out of band flagging which can at least say between requests which keys should be invalidated or worst case reset the whole cache for that user. In theory all caches should be able to be purged at any point in time with no loss of function and be rebuilt on demand - but it is highly likely that various code is abusing the session cache as a store instead of a cache. The headers may have been sent, but perhaps a small chunk of js could be written which sets a cookie which is honored on the next load.

The only 100% correct solution is to fully deprecate cachestore_session and have the default store be probably file based. In prod for anything serious you'd swap this to redis the same as you'd swap the session store to redis.