How to invalidate cache contexts?

Question

When updating my module from Drupal 7 to 8 I bumped into the concept of cache tags and cache contexts. After reading both documentation pages, I have come to the following conclusions:

A cache tag is used to tell Drupal 'what is in the cache', so the cache can be invalidated once something in the cache is updated. This is mainly used for entities and configurations.

Cache contexts provide... context (duh), so the exact same set of tags (entities) can exist under multiple circumstances with a different cache. Examples for contexts are languages and themes, where the same set of entities need to be rendered differently.

Now I did find how to invalidate cache tags:

Cache tags are invalidated using cache_tags.invalidator:invalidateTags() (or, when you cannot inject the cache_tags.invalidator service: Cache::invalidateTags()), which accepts a set of cache tags (string[]).

But I cannot find how to invalidate cache contexts...

The reason for asking this is because I am in the process of converting the white label module to Drupal 8. (This module allows the site name, logo and color scheme to be overridden initially based on a url token, but a session variable for subsequent pages.) So I thought such a whitelabel token would make up for an excellent cache context. However (probably on very low frequency) the parameters (name, logo, etc) could change. Thus I should invalidate the cache context.

Can I invalidate cache contexts? Or are there other options? I have thought of using a combination of both tags and contexts, but I am afraid the amount of combination will go through the roof...

Answer 1

What you describe in your question doesn't look like you need a custom context. If you are thinking about to invalidate something, for example if the site logo is changed in configuration, then this is a tag, it can't be a context.

You can have multiple tags and you can combine tags and context, this is not a problem at all. But you run into trouble if you have too many contexts, because for each combination of contexts you get a cache entry and you will run out of database space quickly. This would be the case if you have too many combinations of name, logo, etc. and would try to use this in a context.

Answer 2

Cache contexts cannot be invalidated.

Cache tags describe data dependencies. Data can change. When data changes, the associated cache tag(s) are invalidated, causing the cached results to get invalidated and then recomputed.

Cache contexts describe context dependencies, which means they describe variations. It's very much like HTTP's Vary header. Cache contexts usually describe input from the request (such as the URL or parts thereof, the requestor's IP address, the associated user, the associated session, or even the matched route), but could also describe some global state such as which day of the week.

You could create a custom cache context for your use case, but it'd be the combination of the url.query_args:whitelabel (assuming ?whitelabel=foo is what you meant) and session cache contexts. But it'd be much simpler to instead just associate those two existing cache contexts!

(Note that using the session cache context makes things extremely uncacheable, because it causes a unique variation per session!)