Problem/Motivation

When the module is enabled and you use some external cache, for example Varnish with long TTL setting you may face the situation when cached pages reference files that were deleted, cause module clears public://js/delayer folder on the each cache flush. And the cache flush doesn't necessarily mean that the external cache of the page will be invalidated too.

Steps to reproduce

- Enable and configure the module
- Enable and configure varnish, set TTL to some long-term
- Ensure that page uses script from public://js/delayer/... folder
- Do any change in a script included into the delayed bundle
- Visit the cached version of the page and see the error in console

Proposed resolution

Use the same approach as core's asset.js.collection_optimizer service (see Drupal\Core\Asset\JsCollectionOptimizer::deleteAll)

Remaining tasks

I'm providing a patch here, but I'm not sure if the threshold should be moved to the module settings or we can keep using the setting from system.performance. Kept that part unchanged for now.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

artem_sylchuk created an issue. See original summary.

artem_sylchuk’s picture

Status: Active » Needs review

Attached the MR

vdsh made their first commit to this issue’s fork.

  • vdsh committed 8e875d2 on 2.1.x authored by artem_sylchuk
    Issue #3215993 by artem_sylchuk: Files are cleared on the each cache...
vdsh’s picture

Status: Needs review » Fixed

Thanks Artem for the detailed explanation & merge request. Doing exactly as in Core in Drupal\Core\Asset\JsCollectionOptimizer::deleteAll, tests are passing, I don't see any reasons to not commit it

I also don't think we need a specific setting for this, as it's reproducing exactly Core's behavior, so let's keep it simple & consistent

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.