Duplicate values in ajaxPageState.libraries

This worked great for me - thanks!

@codesmith

+++ b/core/modules/system/system.module
@@ -726,6 +726,7 @@ function system_js_settings_alter(&$settings, AttachedAssetsInterface $assets) {
+    $minimal_libraries = array_unique($minimal_libraries);

Here is a suggestion: Move this array_unique call into \Drupal\Core\Asset\LibraryDependencyResolver::getMinimalRepresentativeSubset This way unit testing in \Drupal\Tests\Core\Asset\LibraryDependencyResolverTest would totally be possible.

@dawehner : I will refactor previous patch and try to provide it today.

@dawehner : Or is this already fixed in the 8.6.x branch? But I think it only checks this with assert, but does not filter given libraries via array_unique for further processing.

Move array_unique filtering of libraries array to \Drupal\Core\Asset\LibraryDependencyResolver::getMinimalRepresentativeSubset as suggested from @dawehner.

@dawehner : Or is this already fixed in the 8.6.x branch? But I think it only checks this with assert, but does not filter given libraries via array_unique for further processing.

Do you understand why it produces duplicates? Maybe we can fix this different.

The assert right above is already checking for duplicates, I think if there are duplicates we need to find the source(and tests).

assert(count($libraries) === count(array_unique($libraries)), '$libraries can\'t contain duplicate items.');

Per #11 and #13

We don't use this AJAX requests in our projects anymore which was reported by @braindrift in the past, because we already switched to a decoupled frontend solution.

Maybe it comes up from our library handling in our custom parent / child themes we used here in the past.

Perhaps it would be good to replace the assert() call in getMinimalRepresentativeSubset() of LibraryDependencyResolver class to some try catch to get more informations on production environments from other projects which seems to have also this issue.

assert() is a language construct in PHP 7, allowing for the definition of expectations: assertions that take effect in development and testing environments, but are optimised away to have zero cost in production.

Closing out as outdated per #20.

Not something that's been noticed I believe/reproducible.

I just updated a site from Drupal 9.5.10 to 10.1.0 and run into this error now.

I debugged the issue and found that views/views.module is added twice.

In Drupal\Core\Render\HtmlResponseAttachmentsProcessor::processAttachments():

$ajax_page_state = $this->requestStack->getCurrentRequest()->get('ajax_page_state');

This page state contains views/views.module two times.

This quick fix made the site work in the dev environment.

Also happens with 10.1.1.
But it is interesting that it wasn't an issue with 9.5.x.

@mkalkbrenner: Maybe HTTP method for AJAX requests has changed to GET in D10 or D10.1? This was in the past our problem, because we used some patch I think to have GET instead of POST request for AJAX in our project.

Could you double check this? As mentioned in #21 with switch to a decoupled frontend we do not trigger such AJAX requests in our project anymore.

I've just run in to this too.

it does only seem to manifest during during tests run via weitzman ExistingSiteBase tests, but when i step through myself in the brower the libraries are unique.

We're not doing any ajax requests, and the problem goes away when I disable big_pipe.

The library which is being added twice is "facets/drupal.facets.link-widget" (and it's duplicated at the end of the libraries array).

Super odd. I've run out of time to dig any deeper so have just applied the patch :(

Looks like this is still the case with Drupal 11.0.1 too. I just tested this on a standard install of Drupal 11 with only media en media_browser enabled as extra.
When filtering and paginating, the query parameters are duplicated. resulting in a "request URI too long" error on our firewall.

From 10.2.3 onwards this is a problem for all our site's. I found a lot of issues regarding this but all proposed solutions do not work.
Could this be a nginx problem? But I tried this on a docker-drupal setup with apache and it's the same there.

I just don't know where to look in ajax code. Please advise. Thank you.

I also noticed this issue while working on the project.
Drupal core: 10.3.10 with big_pipe module enabled.
Issue was noticed on layout builder edit form where core/components.navigation--toolbar-button library was added twice.

Upon debugging, I noticed that it is present twice in ajax_page_state as well.

I think we should apply array_unique when we push the libraries to ajax_page_state so we always have unique libraries in the ajax_page_state.

I've added a PR with the fix.

Adding patch for the 10.3.x release cycle since current 11.x patch is not cleanly applied on 10.3.x.