👍

@stof FYI

Doesn't the failing test mean that a feature that worked before will break now? Sorry for the question but I am actually not sure what we are testing here at all.

@xabbuh If it is a useful and well designed test, yes.

In this particular case, the test loads translations from a fixture inprod mode. It then repeats this to make sure the cached information is used (all green so far).

Then, in a third step, it re-creates the Translatorwithout adding the resourceand switches todebug mode; it then expects the cache to be invalid.

The problems with this are as follows:

• When using different resource sets, theTranslator should internally make sure it uses different cache files. This is not the case.
• Switching fromprod todebug probably considered the cache stale beforeImplement service-based Resource (cache) validation #15738, because inprod the.meta file was not created. This is, however, an implementation detail not relevant for the working ofConfigCache. So, I'd say that this behaviour has even been fixed now because the resource used (the translation fixture file) is unchanged, to it is right to still consider the cache fresh.

Of course you may ask whether we shouldn't fix the test instead of removing it, but honestly I don't even understand what it actually tries to test for (that hasn't been covered elsewhere already).

Thank you@mpdude.

@mpdude Thank you for your detailed explanation. This makes the reasoning for removing the tests more clear.