JS aggregation returns 400 for libraries loaded in the header only as dependencies

Ha. Thanks for asking. Added to the issue summary.

It looks like the root cause is the first aggregated JS file going 404.

Can anyone else reproduce? Is this a local problem for me?

Thanks for the info.

Still no luck

1. I upgraded ddev to the latest
2. Did a ddev delete -O and ddev config

Still no luck

I also tried other themes.

• I'm unable to reproduce the issue with either Olivero or Stark
• I was able to reproduce the issue with Gin (contrib)

I'm going to ask around on Slack to see if others can reproduce.

Good question. Watchdog is showing the following error:

Type	client error
Date	Wednesday, 5 August 2026 - 08:40
User	admin
Location	https://drupal-admin.ddev.site/sites/default/files/js/js_Br68L5jck8RMhQvktzTv3SEbkgMaOza2J-Nf8Z-KvCY.js?language=en&libraries=eJxLzi9K1U8pKi1IzAlOLSnJzEsvBgBLhwey&scope=header&theme=default_admin
Referrer	https://drupal-admin.ddev.site/admin/appearance
Message	Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid filename. in Drupal\system\Controller\AssetControllerBase->getGroup() (line 245 of /var/www/html/core/modules/system/src/Controller/AssetControllerBase.php).
Severity	Warning
Hostname	172.18.0.5
Operations	

Some additional troubleshooting.

• Going to the URL (https://drupal-admin.ddev.site/sites/default/files/js/js_Br68L5jck8RMhQvktzTv3SEbkgMaOza2J-Nf8Z-KvCY.js?scope=header&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAlOLSnJzEsvBgBLhwey) causes a "Invalid filename." message in the browser (not sure if this is Drupal or the web server).
• The js_Br68L5jck8RMhQvktzTv3SEbkgMaOza2J-Nf8Z-KvCY.js file does not exist
• If I manually create the file, the file will load as expected (which means the filename format works just fine).
• The filename does not change when I do a drush si. I expected the filenames to be random.

I had Claude (Fable) troubleshoot, and it's indicating a core aggregation bug:

From Claude:

Diagnosis

The failing request is the header-scope aggregate for exactly one library, core/drupalSettings. I decoded the compressed libraries= query parameter.

The controller returns the 400 response from getGroup() because it resolves that library to zero header assets, so there is no group at delta 0 to serve.

The causal chain is:

1. default_admin/init is declared with header: true and depends on core/drupalSettings in default_admin.libraries.yml:349.

   Contrib Gin has the identical gin_init pattern, which explains why only these two themes reproduce the issue. Olivero and Stark have no header-scoped libraries, so drupalSettingsLoader.js remains in the footer and everything works.

2. During page rendering, AssetResolver::getJsAssets() expands header libraries with their dependencies in AssetResolver.php:390, so core/drupalSettings is pulled into the header.

   Its loader file becomes its own aggregate group. Because the group maps one-to-one to a library, JsCollectionOptimizerLazy::optimize() takes the new fast path at JsCollectionOptimizerLazy.php:139.

   The generated URL contains:

   ?scope=header&libraries=core/drupalSettings

   rather than the full include, exclude, and delta context.

3. When the browser requests that URL, JsAssetController::getGroups() re-resolves only core/drupalSettings, without its dependents.

   Header placement is computed solely from the header flag on the libraries being resolved in AssetResolver.php:353-358. However, core/drupalSettings does not itself declare header: true.

   Its header placement during the original render came entirely from default_admin/init, which is absent from the regeneration request.

   As a result:

   • The loader resolves to the footer.
   • The header asset set is empty.
   • getGroup([], 0) throws BadRequestHttpException('Invalid filename.').
   • The request returns a 400 response with a text/plain content type.
   • drupalSettings is not defined errors cascade throughout the page.

I confirmed this with a Drush simulation:

• Resolving core/drupalSettings by itself places the loader in the footer.
• Resolving it through default_admin/init, with dependencies, places it in the header.

This also explains the behavior described in comment #8. deliver() serves the file directly when it already exists on disk, as seen in AssetControllerBase.php:120. Therefore, manually creating the file works.

The hash remains deterministic because it is an HMAC of the aggregate group contents.

In summary, the libraries= aggregate URL fast path, introduced as part of the newer aggregate_target work on the main branch, is not safe for header-scope groups whose libraries are present in the header only transitively. The generated URL does not contain enough context to reproduce the original scope.

Fix options

• Controller-side fix (recommended):

  In JsAssetController::getGroups(), when processing a libraries= request, trust the requested scope query parameter instead of recomputing the scope exclusively from the library definitions.

  The URL already asserts that these libraries formed a single group in that scope. This approach would also repair already-cached HTML that points to the broken URL.

  One complication is that each item's scope contributes to the hash. The item scopes must therefore be changed to the requested scope before hashing; otherwise, the request could enter a redirect loop.

• URL-generation fix:

  In JsCollectionOptimizerLazy, skip the libraries= shortcut and fall back to the include-and-delta URL when both of the following are true:

  • The aggregate group is in the header scope.
  • None of the group's libraries independently declare header: true.

  In other words, the shortcut should not be used when the group's scope cannot be reproduced by resolving its libraries independently.

Proposed next step

I can write the core patch and a regression test for the controller-side fix.

I'm currently having Claude write a patch and will verify it solves the issue.

I know @catch has been doing perf work involving aggregation lately. Will ping him in Slack when ready.

I had Claude (Fable) write the code in the MR. Although I can't speak for the code quality, I can verify that it does resolve the issue.

Here's what Claude had to say about this:

What the patch contains

1. The fix — core/modules/system/src/Controller/JsAssetController.php.

   For ?libraries= aggregate requests, getGroups() no longer trusts the recomputed header/footer split. A library such as core/drupalSettings only appears in the header transitively (via default_admin/init's header: true), and that page context is unavailable when the controller re-resolves the library on its own.

   Instead, the controller:

   • Merges both the resolved header and footer scopes.
   • Re-sorts the assets with AssetResolver::sort() to restore the original render-time order.
   • Stamps each asset with the scope provided in the request URL.

   This ensures the generated hash matches the render-time hash exactly, allowing the aggregate to be served successfully and written to disk.

2. Regression test — a new header_assets_test test module.

   The module defines a header: true library that depends on core/drupal (and therefore core/drupalSettings) and attaches it to every page using hook_page_attachments().

   It is wired into AssetOptimizationTest with an assertion verifying that the page generates a header aggregate for transitively-header libraries. The same coverage also applies to AssetOptimizationUmamiTest, which inherits from it.

Validation

• With the fix reverted, the regression test fails with the exact signature of this bug:
  

  Current response status code is 400, but 200 expected.

  on the generated header aggregate.

• With the fix applied, the full test suite passes (245 assertions), including the hash-mismatch redirect assertions, confirming there are no redirect loops.
• On the reproduced DDEV site, the previously failing js_Br68… aggregate URL now returns 200 text/javascript, is written to disk successfully, and both /admin/content and /admin/modules load without any JavaScript console errors.
• commit-code-check.sh passes, including:
  • CSpell
  • PHPStan
  • PHPCS
  • ESLint

Caveats

• The Brotli/Gzip compression assertions are environment-sensitive. Your local DDEV Nginx instance does not include the Brotli module, so assertBrotli() fails locally regardless of this patch. Drupal core CI passes these assertions as expected.
• To reproduce the multi-library case, I temporarily enabled extension_discovery_scan_tests and the header_assets_test module on your development site. Those changes have since been reverted, and the site is back to its original olivero/default_admin configuration.

Updating IS.

Setting this to Major since it breaks what will become Drupal's default Admin theme.

From @catch in Slack https://drupal.slack.com/archives/C079NQPQUEN/p1785941457459889?thread_t...

If the controller fix is correct, that's the better way to fix it because using ?libraries results in much better browser/CDN cache hit rates. It seems like it probably ought to be OK because if it's in the header with another library, it's in the header, it's not going to suddenly move unless the library definitions change.

We should try to get rid of header javascript in default_admin though, separate issue of course.
[10:53 AM]Pretty late here so can't do a proper code review (and out most of tomorrow and the day after too)

Fixing my bad grammar title with something more descriptive.