There request is failing with:

code
: 
"internal_api_error_DBQueryError"
errorclass
: 
"Wikimedia\\Rdbms\\DBQueryError"
info
: 
"[6780f1ed0d1cbc42374d45b6] Exception caught: A database query error has occurred. This may indicate a bug in the software."

Git bisect gives rMWf77eb62e456e: mediawiki.api: Modernize test syntax (async-await, assert.verifySteps) as the reason. Before that I do not even see API requests happening.

After updating everything to latest version and running update.php, the test is no longer failing for me locally, even though requests are made.

Tried rebasing the Translate patch, and it still fails. I don't see anything in the artifacts that would explain why the request is failing.

If I log out, I do see the test failing locally too. Perhaps this newer worked and something in the aforementioned change just caused this test to actually work.

Change 967876 had a related patch set uploaded (by Nikerabbit; author: Nikerabbit):

[mediawiki/extensions/UniversalLanguageSelector@master] Remove broken QUnit test

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

Change 967876 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Remove broken QUnit test

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

In T349485#9271942, @Nikerabbit wrote:

If I log out, I do see the test failing locally too. Perhaps this never worked and something in the aforementioned change just caused this test to actually work.

That'd be my guess, yeah. My change likely got rid of some dirty state that was previously left behind. I temporarily reverted your change in a draft commit with some extra console.log statements:

[WIP] Revert "Remove broken QUnit test"
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/968378

Result:
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-noselenium-docker/133660/console

DEBUG [middleware:source-files]: Requesting /api.php
DEBUG [middleware:source-files]: Requesting /api.php

INFO: 'ext.uls.preferences.js/save/isNamed', true
ERROR: 'ext.uls.preferences.js/save/fail', 'notloggedin', Object{error: Object{code: 'notloggedin', info: 'You must be logged in to edit your preferences.', docref: 'See http://127.0.0.1:9413/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes.'}, servedby: '1169b981d799'}

INFO: 'ext.uls.preferences.js/save/isNamed', true
ERROR: 'ext.uls.preferences.js/save/fail', 'notloggedin', Object{error: Object{code: 'notloggedin', info: 'You must be logged in to edit your preferences.', docref: 'See http://127.0.0.1:9413/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes.'}, servedby: '1169b981d799'}

ext.uls
     ✔ Initial check
     ✔ Custom langdb
     ✖ User preferences
     ✔ Common languages

In case there was a server-side PHP error, you could also click on "Status" in Jenkins and then look for the mw-error.log artefact file, which will contain a stack trace in that case. For the above example, there isn't an mw-error.log file because no uncaught exceptions happened.

I'm not sure which internal_api_error_DBQueryError you got, but if it seems like that's differnet from the one I see in CI now. If you're able to reproduce the internal_api_error_DBQueryError case, you'd be able to check the mw-error.log artefact for details on why that would cause a DB error. I'm guessing that would be unrelated to any client-side code or unit tests, however.

I do note that when I run this locally (if logged-in) the test pass, albeit quite slow at taking 1-2 seconds to complete. Apart from speed, I'd say you generally want to avoid changing stuff in the database from a frontend test (both unit tests and integration tests). It's not really testing anything in your JS code by doing that. You can e.g. stub w.Api().saveOption, which is the method that ULS's javascript code calls, and assert that it is called and then mock a return value for the scenario you're testing.

Change 968783 had a related patch set uploaded (by Abijeet Patro; author: Nikerabbit):

[mediawiki/extensions/UniversalLanguageSelector@wmf/1.42.0-wmf.2] Remove broken QUnit test

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

Change 968784 had a related patch set uploaded (by KartikMistry; author: Nikerabbit):

[mediawiki/extensions/UniversalLanguageSelector@wmf/1.42.0-wmf.1] Remove broken QUnit test

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

Change 968784 abandoned by KartikMistry:

[mediawiki/extensions/UniversalLanguageSelector@wmf/1.42.0-wmf.1] Remove broken QUnit test

Reason:

Already cherry picked

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

Change 968783 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@wmf/1.42.0-wmf.2] Remove broken QUnit test

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

Mentioned in SAL (#wikimedia-operations) [2023-10-26T14:16:13Z] <lucaswerkmeister-wmde@deploy2002> Started scap: Backport for [[gerrit:968783|Remove broken QUnit test (T349485)]]

Mentioned in SAL (#wikimedia-operations) [2023-10-26T14:17:36Z] <lucaswerkmeister-wmde@deploy2002> abi and lucaswerkmeister-wmde: Backport for [[gerrit:968783|Remove broken QUnit test (T349485)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2023-10-26T14:23:07Z] <lucaswerkmeister-wmde@deploy2002> Finished scap: Backport for [[gerrit:968783|Remove broken QUnit test (T349485)]] (duration: 06m 53s)