[04:18:50] Hi! I'm using mwapi to fetch revisions for an article. Strangely, for the article https://en.wikipedia.org/wiki/Apollo_program I'm only getting some sporadic 5-6 revisions, while clearly the article has a long dense history. What could possibly be wrong here? [04:19:12] the api script is correct, since its correctly fetching revisions for some other articles [04:26:24] Can you post the exact api query used? [04:35:27] bawolff: http://dpaste.com/3FE06MP [04:37:50] I meant more as an http url to the api [04:40:12] let me see how to extract mwapi's generated request [05:10:23] bawolff: nvm, the article has a small 'p' in program, has missed that [14:00:31] Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: @Lucas_WMDE & @James_F - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [14:10:19] Someone please tell me the phab task number in which "Special:Contributions/newbies" has been removed [14:11:29] https://phabricator.wikimedia.org/T220447 this one? [14:36:20] oh yeah ... Thank you douglas :-D [14:50:26] Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @Lucas_WMDE & @duesen - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [14:51:08] now with 50% correcterer nicknames! :D [15:01:28] okay, welcome to today’s Technical Advice IRC Meeting! :) [15:02:49] I seem to be missing my co-host, but feel free to ask questions and I’ll do my best… [15:03:56] Hi, I'm working on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/535657 (Injecting services into special pages) but I've hit a snag: There's a recursive service issue with certain extensions. Based on stack traces it seems to be caused by a combination of GlobalPreferences and MobileFrontend [15:04:13] The thing is, I can't reproduce it locally, and I'm not sure how I should proceed with that change. [15:06:48] hm, where are those stack traces? I only see browser test failures in the most recent failed builds [15:07:56] Those are annoying to obtain, so you'll have to browse to the artifacts of the failed build; https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/1733/artifact/ [15:08:05] I'll upload one to phabricator like I did before [15:08:22] ah, in mw-exception.log? [15:08:50] I think? I used the images mostly, but I've extracted one on https://phabricator.wikimedia.org/T232506#5543660 [15:09:06] ah ok [15:09:18] I found https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/1733/artifact/log/mw-exception.log [15:09:27] Neat! [15:10:33] That's indeed the file I got the traces from; I cross referenced them with the failed selenium test based on request ID [15:10:58] ok [15:15:23] * duesen_ wibbles [15:15:32] * Lucas_WMDE waves [15:15:37] am I too late for the technical advice meeting? i was lurking on the wrong channel ;) [15:15:43] Tulsi: Happy to just talk about T220447 here if you wish, too. [15:15:44] T220447: Split out or remove Special:Contributions/newbies functionality - https://phabricator.wikimedia.org/T220447 [15:15:51] duesen_: It's still going. :-)\ [15:16:12] currently looking into CI issues of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/535657 [15:16:31] mainframe98: tried installing GlobalPreferences and MobileFrontend and can’t reproduce it either… [15:17:53] when I put a breakpoint in GlobalPreferences’ Hooks::getPreferencesFactory(), the stack trace looks much shorter [15:18:47] what stack frame? I just see the selenium failure, no stack trace [15:19:06] duesen_: https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/1733/artifact/log/mw-exception.log [15:19:35] oh i see [15:20:00] PermissionManager -> SpecialPageFactory -> PreferencesFactory -> PermissionManager [15:20:21] o_O [15:20:47] sounds like we have to find out how creating PermissionManager triggers the creation of SpecialPageFactory [15:21:12] guess into the blue: something wants to enumerate the names of special pages [15:21:31] Oh, and so needs to know what rights the user has to annotate said list? Yeah, that'd do it. [15:21:53] something like that [15:22:20] From what I could determine at the gerrit change was "that the move of the call to the SpecialPage_initList hook to the service construction is what caused the problem; MobileFrontend does some preference related stuff in a hook handler, which inadvertently calls the PreferencesFactory, which needs the PermissionsManager." [15:23:31] when I try it locally, the SpecialPageFactory is already instantiated in a stack trace that ends in WebStart [15:23:39] a few lines above $mediaWiki->run() in index.php [15:23:57] so I’m not sure why in CI, $mediaWiki->run() is what ends up instantiating these services [15:26:16] all these services should be well set up by the time we leave Setup.php, it seems to me [15:27:33] It really boils down to a conceptual issue [15:27:40] I'm afraid it's not easily resolved. [15:27:57] Special pages need to check permissions. So the SpecialPageFactory needs the PermissionManager. [15:28:10] But PermissionManager takes a SpecialPageFactory as a constructor parameter [15:29:05] What does it do with it? [15:29:11] resolve aliases [15:29:15] still figuring out why [15:30:11] for checking the read whitelist [15:30:27] so, the solution would be to separate special page alias resolution from the actual factory [15:31:03] YetAnotherService™? [15:31:13] yep [15:31:21] Oh goody. [15:31:38] SpecialPageFactory::getAliasList() relies on $this->contLang->getSpecialPageAliases(); [15:31:55] Yay circularity. [15:32:36] increasing granularity is the typical solution for circular dependencies [15:32:54] Something like T231866, but with an increase of services as a solution then? [15:32:54] T231866: Circular dependency when creating service! ContentLanguage - https://phabricator.wikimedia.org/T231866 [15:32:59] so... there is two methods in SPecialPageFactory that are language bases: [15:33:14] getLocalName and getAliasList (and, indirectly, resolveAlias()) [15:33:23] splitting these into a separate service would fix the problem [15:33:54] mainframe98: yes, it'S quite similar, actually [15:34:01] Hmm, that seems doable to me - at least it's something I'd like to try persuing. Is it appropriate to do it in the same patch? [15:34:13] no, separate patch please [15:34:17] ideally, separate ticket, too [15:34:23] bureaucracy, i know... [15:34:36] but higher granularity is good for patches and tickets, too :) [15:34:45] Smaller, simpler patches => faster cycle time. [15:34:52] I shall need no excuse to create a ticket, but I'll take it regardless. [15:34:57] longer chains -> more confusion ;) [15:35:25] mainframe98: thanks for digging in! [15:35:29] I'm not sure I agree. [15:35:41] I can already imagine the approach to take here, at least this has given me something to work with. Thanks all! [15:36:25] Thank you for your work. :-) [15:37:04] yeah, this looks super exciting in the big picture [15:37:11] even if getting there is painful :) [15:37:24] It is the best way to learn though, so I'll take it [15:45:26] any other questions? we still have 15 minutes [15:59:41] James_F: as long as we don't let the small patches pile up, we won't get long chains. so it'S all good :) [16:00:18] I think long chains are a good way to explain the thought process to reviewers (and lookers-on). [16:06:27] anyways, the Technical Advice IRC Meeting is over! [16:06:31] thanks to everyone who participated :) [16:06:47] and you can always ask your questions over at the Wikimedia Developer Support forum: https://grafana.wikimedia.org/d/000000344/wikidata-quality?panelId=11&fullscreen&from=1539101128814&to=1570637128815 [16:06:50] oops ^^ [16:06:54] this one: https://discourse-mediawiki.wmflabs.org/