User Details
- User Since
- Oct 7 2014, 2:31 PM (567 w, 3 d)
- Availability
- Available
- LDAP User
- Umherirrender
- MediaWiki User
- Umherirrender [ Global Accounts ]
Yesterday
Thu, Aug 21
Should be done with phan as the type of the variable is needed.
Similiar how empty and isset are forbidden in some situation.
Wed, Aug 20
Sounds like upstream for codesniffer, maybe macOS is the special part here
Tue, Aug 19
ApiMain::handleException calls MWExceptionHandler::rollbackPrimaryChangesAndLog to rollback the database after any exception, including timeouts.
For the last error the log message shows the user is the empty string (type on initApiRequestObj says string, so user cannot null or false here),
added code to omit the api request. The condition was a falsy check before and changed to check for null only.
Sat, Aug 16
Wed, Aug 13
This would be the opposite of T294397, which removes the writeapi right to not allow to disable the api, as many gadgets and also visual editor requires api.
Not sure what this means for mobile edits via browser or apps.
Tue, Aug 12
It could be the load on CI, but it is also the result of the split, which seems to produce very unbalanced test suites, that run in parallel.
The mysql-error.log of that run contains more information about the deadlock.
The conflict seems between update via JobQueueDB::claimRandom and insert (of two rows) via JobQueueDB::doBatchPush on (non-unique) index job_cmd_token.
Mon, Aug 11
According to the linked task this is fixed. The change was not backported, so the failures some days after the fix seems okay - https://www.mediawiki.org/wiki/MediaWiki_1.39/Roadmap#10
Maybe the merge plugin helps to avoid this situation in the future: https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin
While is task is Invalid, I make it resolved, as a mitigation is backported.
The master branch was updated with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WSOAuth/+/1161037 / d14730a712db8123cb4ffd07575b8241c3fad382
The closures for callbacks should be moved to a new class in own patch set, that could make the review easier (or at least the discussion where to store it).
A variant of this with also "should save an edit" failing (the test before)
Sounds like new problems with the set up code
Sun, Aug 10
The warning message is "Filename has been changed to "$1".".
What was the title in your request? It was adjust to the given value "Расчетный_знак_1_рубль_many_front.jpg", because the requested name does not follow the rules for page names on wikis.
Sat, Aug 9
First failure seems https://integration.wikimedia.org/ci/job/mwext-node20-rundoc/15341/console via "ERROR: "install:bridge" exited with 1."
Thu, Aug 7
Wed, Aug 6
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1175580
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81/32089/console
14:56:52 [Chrome 120.0.0.0 linux #0-1] » /tests/selenium/specs/ipcontributions.js
14:56:52 [Chrome 120.0.0.0 linux #0-1] IPInfo on Special:IPContributions
14:56:52 [Chrome 120.0.0.0 linux #0-1] ✓ should not be shown to users without necessary permissions
14:56:52 [Chrome 120.0.0.0 linux #0-1] ✖ should show an error for IPs without edits after accepting agreement
14:56:52 [Chrome 120.0.0.0 linux #0-1] ✓ should show geo data for IP with edits
14:56:52 [Chrome 120.0.0.0 linux #0-1]
14:56:52 [Chrome 120.0.0.0 linux #0-1] 2 passing (24.2s)
14:56:52 [Chrome 120.0.0.0 linux #0-1] 1 failing
14:56:52 [Chrome 120.0.0.0 linux #0-1]
14:56:52 [Chrome 120.0.0.0 linux #0-1] 1) IPInfo on Special:IPContributions should show an error for IPs without edits after accepting agreement
14:56:52 [Chrome 120.0.0.0 linux #0-1] element ("button[name=submit-agreement]") still not displayed after 5000ms
14:56:52 [Chrome 120.0.0.0 linux #0-1] Error: element ("button[name=submit-agreement]") still not displayed after 5000ms
14:56:52 [Chrome 120.0.0.0 linux #0-1] at async IPContributionsWithIPInfoPage.acceptAgreement (/workspace/src/extensions/IPInfo/tests/selenium/pageobjects/IPContributionsWithIPInfoPage.js:44:3)
14:56:52 [Chrome 120.0.0.0 linux #0-1] at async Context.<anonymous> (/workspace/src/extensions/IPInfo/tests/selenium/specs/ipcontributions.js:76:3)Tue, Aug 5
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1172137
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81/31940/console
00:51:13 [0-2] Error in "Client Hints."before all" hook for "Verify edit sends Client Hints data"" 00:51:13 Node is either not clickable or not an HTMLElement 00:51:13 Error: Node is either not clickable or not an HTMLElement 00:51:13 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 00:51:13 [0-2] RETRYING in chrome - /tests/selenium/specs/clienthints.js 00:51:15 [0-2] RUNNING in chrome - /tests/selenium/specs/clienthints.js 00:51:19 [0-4] Error in "Temporary Accounts Onboarding Dialog.Verify onboarding dialog displays correctly and IPInfo preference works" 00:51:19 Error: Dialog did not open in time 00:51:19 at async Context.<anonymous> (/workspace/src/extensions/CheckUser/tests/selenium/specs/tempAccountsOnboarding.js:46:3) 00:51:20 [0-4] RETRYING in chrome - /tests/selenium/specs/tempAccountsOnboarding.js 00:51:21 [0-4] RUNNING in chrome - /tests/selenium/specs/tempAccountsOnboarding.js 00:51:23 [0-0] PASSED in chrome - /tests/selenium/specs/checkuser.js 00:51:33 [0-4] PASSED in chrome - /tests/selenium/specs/tempAccountsOnboarding.js (1 retries) 00:51:38 [0-2] Error in "Client Hints.stores client hints data on successful logins" 00:51:38 Error: expect(received).not.toBeFalsy() 00:51:38 00:51:38 Received: "" 00:51:38 at Context.<anonymous> (/workspace/src/extensions/CheckUser/tests/selenium/specs/clienthints.js:127:35) 00:51:38 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 00:51:43 [0-2] FAILED in chrome - /tests/selenium/specs/clienthints.js (1 retries)
Not hanging, but failing in a flaky manner
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1172136
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81/31802/console
Selenium jobs (browser tests) seems tracked under T389536: Selenium timeouts can cause the job to remain stuck until the build times out, this is more about phpunit
https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/1175636
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81/31915/console
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/1175525
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81/31912/console
SessionManager::__construct calls register_shutdown_function with a reference to $this, holding the session manager object until shutdown. For tests the shutdown is the end of phpunit (as far I have understand it).
Looking at the previous passed WikibaseMediaInfo patch set (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/1175870) it seems possible that some jobs take longer, but some passed before the 60 minute timeout, some afterwards.
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php81/23812/console : SUCCESS in 37m 45s https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php82/9853/console : SUCCESS in 32m 12s https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/9312/console : SUCCESS in 53m 44s
Something in CI make this jobs generating wait time or deadlocks or such on the last split group.
Without splitting there would be processing markers for the one running thread. With the splitting there are no process markers and it looks like the job is hanging, but often the tests taking 43 minutes, just 40 minutes longer as all the other splits.
All failing tests are api tests.
Looking at the mw-debug-cli.log there is:
Mon, Aug 4
Used by the supported REL1_39, should be archived after REL1_39 is EOL, to avoid the message about abandoned package when running composer.
It must use the content language as it allows to add own expiry times from the community to the drop down box, that would not work when showing in user language.
Not sure if the message supports language converter syntax in the first part of each entry (before the colon and after comma).
To simplify the regex used to generate the autoload array (in ClassCollector), this should be catched with codesniffer.
The wrong data insert should be already fixed with a7df0148d823d096506deedc774b9e234ff12aa3 (included in REL1_39).
Semantic MediaWiki should not insert own (wrong) data into the table, but not sure about that.
I have not seen the section about coding style. In that case this task is invalid and I should add a "good" test.
The reorder of code in 7432b218160a85219a9f9a4d76f7ba3debb206b8 within the script makes this broken when there are more files as the batch size.
Sun, Aug 3
I would expect the /** @var type */ above the property, not as documentation of the constructor. The type for the real-typed properties is also nearby, so using @param on the construtor looks wrong here.
Sat, Aug 2
The library should be kept active until the last supported MediaWiki release with this library is EOL. This allows to support security patches on the library.
Maybe add a note to readme, similiar to trigger deprecation warning. But composer should not auto-update to the new version for older MediaWiki versions.
It's done. The relevant sniffs are now enabled on core. The codesniffer should now detect missing documentation for new functions.
There a still issues (flaky tests)
https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-sqlite-php81/1004/consoleFull
Same as comment before
12:28:28 1) MediaWiki\Tests\Api\ApiClearHasMsgTest::testClearFlag 12:28:28 Wikimedia\Services\RecursiveServiceDependencyException: Recursive service instantiation: Circular dependency when creating service! MessageCache -> MessageParser -> ParserFactory -> LinkRendererFactory -> TitleFormatter -> GenderCache -> UserOptionsLookup -> UserOptionsManager -> _DefaultOptionsLookup -> UserIdentityLookup -> ActorStoreFactory -> UserNameUtils -> TitleParser -> InterwikiLookup -> ConnectionProvider -> UserNameUtils
Fri, Aug 1
Not sure if really fixed, but situation should be better.
On the first day of each month the maintenance script recountCategories.php --mode all is running to correct some wrong category counts. It seems today it broke the counts.
Thu, Jul 31
@hashar has changed access rights from "ldap/wmf" to "Gerrit Managers" => https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/+/8bf70087e1e2412f85c23f3e03a48c773f7d7ed4%5E%21/#F1