[13:54:39] tgr: "Beta Wikitech" meaning labtestwikitech.wikimedia.org, or something else? [13:54:57] yes [13:55:20] enabled there, didn't see any problems [13:55:39] Did someone make labtestwikitech.wikimedia.org start following a train since the last time I looked? [14:01:40] it sort of follows the train, but you need a manual scap pull to update the code [16:42:05] tgr: Hmm. I wonder if T110448 being reverted will blow up anything on Beta. Are you looking at being able to un-revert it already? [16:42:05] T110448: Update AbuseFilter to use AuthManager - https://phabricator.wikimedia.org/T110448 [17:34:37] anomie: I will write the new extension registration patch shortly, but in any case AF uses the AbortXAccount hooks so it should work with AuthManager [17:36:40] Is the JsonConfig AuthManager blocker task closable or should I prod someone (? yurik ?) to help fix it? [17:37:17] James_F: Last I heard yurik still had to actually create a bot password for his user and adjust configuration to use it. [17:37:27] OK, will ping him then. :-) [17:37:27] James_F: it's done on our side but yurik still needs to update the password config [18:57:19] Hm.. does MediaWiki-Vagrant use external store by default? I think that may be what caused revisions to seemingly be missing. [18:57:30] All edits I made while Flow role was enabled are now inaccessible. [18:57:42] text db contains external store entriees instead of raw text. [18:57:53] So flow role ends up enabling it for all revisions, and then... ugh. [19:01:57] Krinkle: the flow role does turn on ES. Maybe you can work with matt to fix up the config so it only effects flow? [19:02:38] Collab uses mw-vagrant a lot and have added a lot of dependencies to the roles they ues [19:02:42] *use [19:02:49] bd808: https://phabricator.wikimedia.org/T136969 [19:02:55] Thanks [19:04:47] I poked them at one point about splitting things up a bit. It might be easier for them to have a collab role that does all their prod-like customizations rather than cookie licking the general roles [20:19:44] ostriches: are you around? [20:20:29] Yo yo yo [20:21:27] ostriches: hi! I have a question for you about this: https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/commit/18820d426187908b1aaee3bb2dbdf4c4d2363519 [20:22:06] ostriches: could you help me with that is going on there - esp. why we need to specify revid there if it's always the latest id anyway? [20:22:56] The comment says it. It could in theory not be the latest revision (at least when I wrote that code) [20:23:20] So if you've got revision 1 that's indexing, revision 2 could've been written since the initial job was inserted. [20:24:38] Much more likely to happen when doing an full index build for an active wiki. [20:25:02] (ie: you inject thousands or millions of jobs, but some of them are edited after the fact before queue drains) [20:25:20] ostriches: but doesn't $page->getRevision() returns the latest rev? that's what phpdoc on it says [20:25:47] * Get the latest revision [20:25:47] It might! This has been 3 years lemme look closer. [20:26:19] Bah, you are right! [20:26:26] So it doesn't even work like I thought lol [20:27:21] "Did you test this?" [20:28:05] heh ok :) [20:28:35] ostriches: so I'm refactoring this code anyway, but I thought I figure out what it's trying to do first. So looks like it just always uses latest rev [20:29:59] so the question is now - if I pass null revId to Content::getParserOutput, would that mean latest rev too? or that wouldn't work? [20:33:55] So WikitextContent::fillParserOutput() expects a $revId, but AbstractContent gleefully passes it a null [20:33:59] Continuing the trail.... [20:35:21] Holy crap WikitextContent uses $wgParser. [20:35:25] * ostriches cries a little [20:36:05] yes it most definitely does [20:36:07] SMalyshev: So yeah it eventually all goes back to Parser::parse() which will happily look up the latest revid if you don't give it one [20:36:29] So: your assumption is correct, the code in Cirrus isn't doing what it claims. [20:36:45] aha, ok. so then the question would be, shoud I still give it proper revId (albeit always latest) or just pass null there? [20:37:01] I mean which one is (or supposed to be) safer and the Right Thing (TM)? [20:37:10] if I start with having WikiPage [20:37:36] The latest rev id is nice if we have it, it'll save a DB hit in the parser :p [20:41:02] ok, I'll keep the ID there then [20:54:00] ostriches: thanks for digging into it :) [20:59:18] yw