We could document somewhere that running MW with xdebug requires xdebug.mode to not include develop. Could even throw an error if xdebug is loaded and this setting is incorrect.

In T402278#11105808, @Lucas_Werkmeister_WMDE wrote:

In T402278#11104848, @bvibber wrote:

After some poking around at repro: disabling xdebug resolves the error on my homebrew-given PHP 8.4.11 install on macOS.

Can confirm, disabling zend_extension=xdebug makes the styles show up on my wiki. Amazing.

The fixes are backported to wmf.15.

Consistently reproducible when editing a page without being logged in: the edit stash API request in the background attempts to evaluate abuse filters to try and reuse the cached result for the actual save, but the user account is an IP user so UserIdentityLookup won't find anything. It's probably not safe to try to cache the result here because the user_name variable will differ between the stash execution (where it is set to an IP user) and the actual edit attempt (where it will be a temporary user).

Proposed patch:

The script calls UserOptionsManager::setOption in a loop, which inits UserOptionsCacheEntry instances for each user. These never get evicted, so memory growth from this would scale linearly with the number of users processed on a given wiki. Edit: these should be cleared when saveOptionsInternal() runs.

Re-opening since ext.securepoll.special.css will need updating too per description.

The table has been created, so the error shouldn't happen anymore. I don't have the requisite permissions on enwiki to confirm myself though.

For now, we could define a cache version in code and manually update it if mediawiki-config changes.

@gmodena Thanks for your comments!

In T390753#10862115, @ecarg wrote:

Thank you @mszabo ! I've opened a couple of MR's that requires instrumentTelemetry.js inside server.js so that it gets run when server.js does. Perhaps we can do this instead of updating the blubber file? I wasn't able to add you as a reviewer so I tagged @akosiaris! However would love your thoughts!

In T395214#10855722, @matmarex wrote:

Minerva has some special cases for viewing the main page, and it seems those cases no longer trigger in tests – Title::isMainPage() returns false when it should return true.

That method has an internal cache, maybe the wrong value is being cached in some other test?

I can't reproduce the failure locally.

I recommend https://gitlab.wikimedia.org/mszabo/the-worst-cloud-provider-you-have-ever-seen for local testing.

In T390753#10848235, @Jdforrester-WMF wrote:

In T390753#10846175, @mszabo wrote:

In T390753#10801695, @ecarg wrote:

Updated backend telemetry config:

• orch
• eval

However, after deploy today, both services can no longer be found in the list of 'Service' dropdown to even select from on [[ Jaeger UI | https://trace.wikimedia.org/ ]] (they formerly existed).

It seems those commits updated package.json to load the instrumentation wiring prior to running server.js, but the blubber spec isn't loading this file. It might need to do the same.

That's not needed, as we copy the whole of the base repo for the orchestrator (unlike the evaluator, where we have to manually tell blubber to copy it:

$ docker run --rm -it -w /srv/service --entrypoint /bin/bash docker-registry.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator:latest

runuser@1503d2237ac0:/srv/service$ ls -l instrumentTelemetry.js
-rw-rw-rw- 1 somebody somebody 822 May  6 14:30 instrumentTelemetry.js

$ docker run --rm -it -w /srv/service --entrypoint /bin/bash docker-registry.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator/wasm-javascript-all:latest

runuser@1f304f891068:/srv/service$ ls -l instrumentTelemetry.js
-rw-rw-rw- 1 somebody somebody 822 May  7 00:42 instrumentTelemetry.js

$ docker run --rm -it -w /srv/service --entrypoint /bin/bash docker-registry.wikimedia.org/repos/abstract-wiki/wikifunctions/function-evaluator/wasm-python3-all:latest

runuser@a156aae36c4e:/srv/service$ ls -l instrumentTelemetry.js
-rw-rw-rw- 1 somebody somebody 822 May  7 00:42 instrumentTelemetry.js

In T390753#10801695, @ecarg wrote:

Updated backend telemetry config:

• orch
• eval

However, after deploy today, both services can no longer be found in the list of 'Service' dropdown to even select from on [[ Jaeger UI | https://trace.wikimedia.org/ ]] (they formerly existed).

We'll need to update patch #4 due to T394900.

In T394070#10843281, @Dreamy_Jazz wrote:

Still seeing this error in production at https://en.wiktionary.org/w/index.php?api=mw-extra&title=Special%3ARestSandbox if I click "Submit":

https://logstash.wikimedia.org/app/dashboards#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2025.05.20?id=1Um775YBKTAjX19wRE9D

+2

+2

PreliminaryCheckPager seems to suffer from the same issue. Should we fix it in this ticket?

+2

It seems the CheckUser issue is only present on master. Would it be acceptable to deploy the fix publicly via gerrit?

And for CheckUser:

Proposed patch:

This dashboard has existed for a while now at https://grafana.wikimedia.org/d/aca1a0f7-5527-4595-ade3-bf09d6219a58/checkuser-globalcontributions?orgId=1&from=now-6h&to=now&timezone=utc. Closing as resolved.

QA Notes

Closing per above and per discussion. The linked improvement tasks could eventually allow these conditions to be removed; however, this is not part of nor a blocker for temporary accounts work.

Looks like that's the user name of the temporary account placeholder initialized by PermissionManager for autocreate actions:

#0 /var/www/html/mediawiki/includes/user/UserFactory.php(364): MediaWiki\User\User->setName()
#1 /var/www/html/mediawiki/includes/Permissions/PermissionManager.php(460): MediaWiki\User\UserFactory->newTempPlaceholder()
#2 /var/www/html/mediawiki/includes/Permissions/PermissionManager.php(291): MediaWiki\Permissions\PermissionManager->getPermissionStatus()
#3 /var/www/html/mediawiki/includes/Permissions/UserAuthority.php(380): MediaWiki\Permissions\PermissionManager->userCan()
#4 /var/www/html/mediawiki/includes/Permissions/UserAuthority.php(171): MediaWiki\Permissions\UserAuthority->internalCan()
#5 /var/www/html/mediawiki/includes/user/User.php(3304): MediaWiki\Permissions\UserAuthority->probablyCan()
#6 /var/www/html/mediawiki/includes/Output/OutputPage.php(4233): MediaWiki\User\User->probablyCan()
#7 /var/www/html/mediawiki/includes/Output/OutputPage.php(3876): MediaWiki\Output\OutputPage->getJSVars()
#8 /var/www/html/mediawiki/includes/Output/OutputPage.php(3898): MediaWiki\Output\OutputPage->getRlClient()
#9 /var/www/html/mediawiki/includes/skins/Skin.php(692): MediaWiki\Output\OutputPage->headElement()
#10 /var/www/html/mediawiki/includes/Output/OutputPage.php(3286): MediaWiki\Skin\Skin->outputPageFinal()
#11 /var/www/html/mediawiki/includes/exception/MWExceptionRenderer.php(197): MediaWiki\Output\OutputPage->output()
#12 /var/www/html/mediawiki/includes/exception/MWExceptionRenderer.php(116): MediaWiki\Exception\MWExceptionRenderer::reportHTML()
#13 /var/www/html/mediawiki/includes/exception/MWExceptionHandler.php(137): MediaWiki\Exception\MWExceptionRenderer::output()
#14 /var/www/html/mediawiki/includes/exception/MWExceptionHandler.php(241): MediaWiki\Exception\MWExceptionHandler::report()
#15 /var/www/html/mediawiki/includes/MediaWikiEntryPoint.php(222): MediaWiki\Exception\MWExceptionHandler::handleException()
#16 /var/www/html/mediawiki/includes/actions/ActionEntryPoint.php(79): MediaWiki\MediaWikiEntryPoint->handleTopLevelError()
#17 /var/www/html/mediawiki/includes/MediaWikiEntryPoint.php(208): MediaWiki\Actions\ActionEntryPoint->handleTopLevelError()
#18 /var/www/html/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()

In T393284#10798070, @Jdlrobson wrote:

The two issues you raise actually seem like positives to me. Generally I would be worried about encouraging the writing of tests in two different libraries and the fragment it leads to. To be truly honest I would love on the long term for us to move fully away from QUnit to Jest in core and that is at least what I am seeing in new extensions. Jest has various benefits such as quicker execution and code coverage scores/enforcement.

• testing inside a real browser tends to be slow and I think is better suited for integration tests such as Selenium and Pixel
• The inability to load ResourceLoader encourages the writing of better unit tests scoped to the functionality of the module being tested.

In T378287#10797708, @Leijurv wrote:

@Novem_Linguae Possibly that ticket is resolved as of a few hours ago? Per: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=2298496&oldid=2298493