When running the qunit job in jenkins for wikibase.git it also fails without that setting.

Change 193130 had a related patch set uploaded (by JanZerebecki):
Change default of $wgResourceLoaderMaxQueryLength to 2000

https://gerrit.wikimedia.org/r/193130

This change (Ic416def846f361425c46f7b) in general seems fine. However I'd like to see further evidence that the QUnit jenkins job is indeed failing because of this. And as a general practice it seems to me that requesting so many modules in one request means one of two things:

• The relevant software is incorrectly using the ResourceLoader module system. (E.g. using it as a complete class registry.) This has all kinds of scalability impacts and semantic "fragileness" to it that warrants addressing. Take an example after VisualEditor where class and file count is very high, but module count is low.
• Software is using overly long module names.

It is definitely too naive for ResourceLoader not have a limit by default. However I argue this limit should never be reached. If this limit is reached, we're talking about failure mode / error handling / graceful degradation, not normal modus operandi.

I suppose the test is slightly different in that it requests everything at once in a way production never would. A quick check to verify that is the case would be nice.

We may want to add a logged check to mediawiki.js asserting the request is shorter. It'd be tolerated in tests (until we find a better way to deal with that).

Test run without that setting: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit-experiment/9/consoleFull
And with that setting: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit-experiment/10/consoleFull

The test run without that setting failed even though it shows as green because --force was added as an argument to qunit.

In T90453#1073327, @Krinkle wrote:

• The relevant software is incorrectly using the ResourceLoader module system. (E.g. using it as a complete class registry.) This has all kinds of scalability impacts and semantic "fragileness" to it that warrants addressing. Take an example after VisualEditor where class and file count is very high, but module count is low.

I'd like to have a discussion about this resp. ask you some questions regarding that. I don't know where the right place for that would be, though.

It is definitely too naive for ResourceLoader not have a limit by default. However I argue this limit should never be reached. If this limit is reached, we're talking about failure mode / error handling / graceful degradation, not normal modus operandi.

Dropping to some failure mode seems quite arbitrary to me. I can't see any inherit reason for this to not just work as it does. Logging a warning is something different, that might make sense.

For Wikidata this has been resolved for now by https://gerrit.wikimedia.org/r/196241.

Change 193130 merged by jenkins-bot:
Change default of $wgResourceLoaderMaxQueryLength to 2000

https://gerrit.wikimedia.org/r/193130

Change 200937 had a related patch set uploaded (by JanZerebecki):
Do not set $wgResourceLoaderMaxQueryLength for tests

https://gerrit.wikimedia.org/r/200937

Change 200937 merged by jenkins-bot:
Do not set $wgResourceLoaderMaxQueryLength for tests

https://gerrit.wikimedia.org/r/200937