[00:35:17] thx [08:24:50] o/ got a question on the CirrusSearch help desk that I doubt is directly related to cirrus, I'm a bit puzzled to understand what's happening on their install (MW 1.39 & class loading issues: https://www.mediawiki.org/wiki/Topic:Yg6g78li1kxvioai) [12:16:24] Could be some weird opcache bug [12:16:37] Or some other error that they've not noticed [13:13:47] Or using an older version of AbuseFilter, the class was created in 1.37 [13:16:47] though I guess if the file exists physically, that can't be the problem [13:17:36] anyway they should add some debug output just before the exception is thrown, and check the autoloader is installed, the autoloaded namespaces include AbuseFilter etc. [14:09:48] dcausse: I also took a stab on this one, didn't notice tgr already answered. I tried to repro but I don't know exact versions and would be great to know if this is an error after update, or are they trying to install multiple extensions and now it started to fail [14:10:46] one thing that I assume, if files are there, looks like the `wfLoadExtension('AbuseFilter')` was called because it can pick up the`AbuseFilter/includes/ServiceWiring.php` file - but I wonder if they have the `merge-plugin` set up correctly [14:11:23] https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin -> if this is missing, or theyu specified extensions by hand and forgot to add AbuseFilter autoloading won't work [14:13:01] thanks all, I'll try to prep a response [14:45:00] pmiazga: thanks for your response! <3 [14:49:18] You shouldn't need merge-plugin unless there is a bug in AbuseFilter [14:50:05] no need for it? do we have another way to autoload things? [14:51:14] Yes, generally the composer autoloader in the extension's vendor will get loaded if you don't have merge plugin setup [14:51:17] ah, right. the `AutoloadNamespaces` is our thing, ExtensionProcessor is doing it. [14:53:06] So for composer dependencies, if you don't have merge plugin setup, you would have to run composer install in the extension directory, but you don't need merge plugin. If you download the extension from mw.org, it comes with vendor prepopulated, so things will just work without running composer at all (For the people in a time machine who only have ftp access) [14:53:13] the autoloading looked off because I recall that you usually need to specify "psr-" standard - but yeah. [14:53:25] but this would try to pick ip the `"$dir/vendor/autoload.php";` [14:53:41] if that file is not there - it wont work - so probably it would require at least `composer install` in AbuseFilter [14:54:43] and the AbuseFilter has `load_composer_autoloader` [14:56:38] If its only happening for them when running the maintenance script, i wonder if that means they have some sort of relative path somewhere important in their LocalSettings.php . Its odd that this type of error would only happen when running a maintenance script [14:56:51] dcausse: the merge-plugin idea might be incorrect, probably won't hurt - but it would be good to check if this person has `AbuseFilter/vendor` folder populated [14:57:31] There is no vendor in the backtrace, so i think its unlikely to be a composer issue [14:58:27] pmiazga: ack [14:59:29] bawolff: there is none, but it tries to autodiscover `RuleCheckerFactory` class from `AbuseFilter/includes/ServiceWiring` file. I wonder if this is the only file it cannot find. [15:00:23] saw on other "similar" issues cases where wfLoadExtension was done conditionally, but here since the AbuseFilter's ServiceWiring file is loaded it must have run wfLoadExtension( "AbuseFilter" )... [15:01:17] yeah, but the autodiscovery uses mw core's autoloader, not composer's [15:02:17] Autloade has to partially work, because this most likely fails when parsing the ServiceWiring file [15:03:09] from what I see - it happens when `loadWiringFiles()` is called, and this happens when `$wiring = require $file;` is executed [15:03:47] parsing ServiceWiring file is probably the first time that MediaWiki would have to autoload a class from the extension [15:03:48] so it tries to create an array, goes entry by entry, and fails on ` RuleCheckerFactory::SERVICE_NAME => static function ( MediaWikiServices $services ): RuleCheckerFactory {` [15:04:22] so ities to unwrap `RuleCheckerFactory::SERVICE_NAME` -> which causes the autoloader to trigger and fail [15:04:29] so it tries* [15:04:43] The fact that this is happening with AbuseFilter which starts with A, makes me think all extensions are broken for this person, as its quite a coincidence that it breaks on the first extension in alphabetical order [15:05:20] probably no, because if you look as ServiceWiring, above you have `FilterUser::SERVICE_NAME => static function ( MediaWikiServices $services ): FilterUser {` [15:05:27] so it probably loaded the FilterUser [15:05:33] sorry, I need to go, will be back later. [15:05:44] will keep thinking about it [15:07:03] hmm, true [15:12:15] they have a mixed setup trying to upgrade from 1.36 or below to 1.39? (RuleCheckerFactory::SERVICE_NAME was introduced in 1.37 apparently https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+/a722dfe1a4494e2a82f6dbc1afca9a21559fc588) [17:43:46] it seems like actually requiring a file is gated behind an is_file check: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/REL1_39/includes/AutoLoader.php#210 [17:46:20] so I think the only thing that can go wrong is converting from relative to absolute path: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/REL1_39/includes/AutoLoader.php#228 [17:47:29] bit surprising that that happens after is_file [17:48:12] so I could see this happening if they have multiple mediawiki versions in their classpath or something like that [17:48:31] anyway should be pretty easy for that person to debug