Sudden cache collisions (newly added site)

Alright, just found out that by default the highest database count in redis is 16, with its 0-based index being 15.
The newly added site used index 16 – so redis seems to fall back to the highest possible the index – which is already used by the other site where the collision occurred.

But why wasn’t the salt being used – as last mitigation measure?
Edit: The salt checked for by the plugin is the constant WP_CACHE_KEY_SALT.
In contrast, the redis server host, username and password are expected to be in $_SERVER instead. This inconsistency was an oversight of me.

• This reply was modified 3 years, 1 month ago by strarsis.

Sorry for the troubles, @strarsis !

Need anything else on our end?

It was an oversight by me, though the salt being a constant while the other redis connection config residing in $_SERVER contributed a bit to this accidental mix up.

Some ideas concerning cache collisions (when running multiple sites that all use one Redis server, which is popular):

1. Does a Redis server emit a notice/warning when a database index higher than the set up max database index number is used by the client? If this is the case, WP Redis could show a warning message in backend.

2. Is there a particular reason why the key salt is expected to be in a constant in contrast to being in $_SERVER as the other redis connection configuration? Because it isn’t a connection setting that doesn’t concert the Redis server?
On the other hand, this has been the case for a very long time now, so it shouldn’t be changed, maybe extended to other locations the salt can be expected to be in ($_SERVER).

3. Can a default salt be used, e.g. the site name or maybe a GUIID?

4. (Similar to point 3.) Can WP Redis detect a cache collision on its own and show a warning in backend? Like storing something unique and site-specific under some key and when it finds an existing value that mismatches, it is probably a cache collision with another site/setup?

It was an oversight by me, though the salt being a constant while the other redis connection config residing in $_SERVER contributed a bit to this accidental mix up.

Makes sense — no worries.

Does a Redis server emit a notice/warning when a database index higher than the set up max database index number is used by the client? If this is the case, WP Redis could show a warning message in backend.

I’d be open to a pull request if this is something you want to explore!

Is there a particular reason why the key salt is expected to be in a constant in contrast to being in $_SERVER as the other redis connection configuration? Because it isn’t a connection setting that doesn’t concert the Redis server?
On the other hand, this has been the case for a very long time now, so it shouldn’t be changed, maybe extended to other locations the salt can be expected to be in ($_SERVER).

WP_CACHE_KEY_SALT is a constant out of WordPress core, while $_SERVER is from the original implementation of WP Redis. Different origin stories, essentially.

Can a default salt be used, e.g. the site name or maybe a GUIID?

This would require an additional database lookup on every request, so probably an over-optimization at this point.

Can WP Redis detect a cache collision on its own and show a warning in backend? Like storing something unique and site-specific under some key and when it finds an existing value that mismatches, it is probably a cache collision with another site/setup?

Potentially, yes, although this seems like another over-optimization. Is there something we could make more obvious in the installation instructions? https://cln.sh/x5j9YS