At least major, potentially critical.
Citing @catch in #2451679-51: Validate cache contexts (+ cache contexts in some views plugins wrong):
+++ b/core/lib/Drupal/Core/Cache/CacheContexts.php @@ -221,4 +221,54 @@ public static function parseTokens(array $context_tokens) { + throw new \LogicException('"' . $context_id . '" is not a valid cache context ID.');Slightly concerned about the following scenario:
1. Enable a module that provides a cache context
2. Some stuff gets cached using that cache context
3. The module is uninstalled
4. The stuff is still cached and this condition gets hit when it's returned from cache.We're moving towards selectively clearing caches when modules are uninstalled, so this feels not impossible to hit as a condition.
Is this worth thinking about more? If it's worth thinking about, I'd suggest making the exception a trigger_error() call instead, then opening a follow-up to make it an exception. That situation is something a real site could very possibly run into, and a developer probably wouldn't.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | module_uninstall_clear_render_cache-2460013-3.patch | 992 bytes | wim leers |
Comments
Comment #1
wim leersFrom #2451679-54: Validate cache contexts (+ cache contexts in some views plugins wrong):
Comment #2
catchBumping to critical for now, we can always bump it down later but this feels like unrecoverable site-breakage if it happens (at least not without drush).
Comment #3
wim leersSimplest patch possible.
Comment #4
catchThere's also the possibility that a module code update renames or removes one of these as well as uninstall. Suggested trigger_error() in the other issue - we may need to make this a non-fatal.
Comment #5
wim leersBut we cannot possibly detect that? So… renames basically mean all you can do is write an update hook…?
Comment #6
catchYes we can't detect that, that's why I suggested non-fatal.
So:
1. Validation - trigger_error() instead of throwing an exception.
2. Before calling the service check if it exists, if it doesn't, trigger_error() and treat the cache item as invalid.
Something like this.
Comment #7
fabianx commentedI like #6 and using trigger_error, once we have an assertion and not do the check at run-time at all, this will be a similar "fault".
Comment #8
berdirNote that uninstalling modules explicitly clears all caches I don't think you will be able to write tests for that scenario, it shouldn't happen.
Yes, where it could happen is when modules are updated/changed, but then you're supposed to run a cache clear/update.php anyway, anything could be broken then.
Not sure this is critical, I'd say demote unless we have a test case that it can happen on an easy to reproduce scenario?
Comment #9
wim leersAre you sure? Unless I made a mistake, that's not actually true!
Comment #10
berdirPretty sure :)
#2359369: Render cache is not cleared when module is uninstalled
at the end of uninstall().
Comment #11
mpdonadioModuleInstaller::uninstall() has this at the end
I think #2359369: Render cache is not cleared when module is uninstalled restored this.
Comment #12
wim leers#11: that links to this issue :)
Comment #13
berdirHaha, that code is broken :) But the same exists in drupal_flush_all_caches(), so that is broken too?This should use Cache::getBins().I'm stupid, that should work fine. Being able to read code would be a huge advantage.
Comment #14
mpdonadio#12: Bad copy paste searching for that issue. Also edited it before I saw your comment. Gotta love multiple cross posts...
Comment #15
larowlanSo it this an issue or not? Seems to be consensus that uninstall == cache clear == problem solved?
Comment #16
wim leersAFAICT: indeed, this is not a problem. The code cited in #11 does ensure the render cache (and all other caches) are cleared.
Regarding the rename problem that catch pointed at in #4 (i.e. what if a module renames a cache context?), that's already taken care of by #2451679: Validate cache contexts (+ cache contexts in some views plugins wrong).
Which means that no problems remain!
(This is one of those rare times that we can close a critical within a week, without a patch :))
Comment #17
wim leersAlso, I still remember testing this and indeed not seeing the
cache_renderDB table being emptied. I really wonder what I did wrong back then, because clearly, that does happen. PEBKAC, of course.