[00:08:43] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization, 5Patch-For-Review: Special:GlobalRenameRequest is notifying all users with a shared name of a completed request - https://phabricator.wikimedia.org/T93444#1143690 (10Krenair) Deployed and confirmed with the help of @DerHexer [03:14:20] hi legoktm, yt? [03:15:53] or duploktm [03:29:24] (never mind. i wrote an article about some musician that got speedy-deleted and wanted it restored to my user page. harej helped out.) [03:30:10] ori: here now. :( [03:30:24] 'sokay, harej helped [03:48:42] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1143982 (10Beebs.systap) >>! In T90115#1143393, @csteipp wrote: > Talked with Nik today about running this. We're planning to expose sending raw queries into our cluster.... [04:42:52] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1144018 (10GWicke) > At the application (proxy?) layer, we'll setup some per-ip/user throttles, and make sure we set appropriate timeouts We should probably not expose an... [04:51:55] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1144216 (10Smalyshev) Memory may be a bigger issue than time. I've experienced some queries that OOM the VM and bring the whole server to unstable state. [06:06:17] 7Blocked-on-MediaWiki-Core, 10MediaWiki-User-preferences, 10MediaWiki-extensions-ContentTranslation, 5ContentTranslation-Release4, and 2 others: CX beta-feature does not stay enabled - https://phabricator.wikimedia.org/T92232#1144291 (10Nikerabbit) a:5KartikMistry>3Nikerabbit [13:20:29] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1144878 (10Thompsonbry.systap) The analytic query mode does offer some ability to bound memory but it is not 100% across all queries. For example, quads mode queries do n... [15:53:49] <^d> manybubbles: When changing content namespaces can I get away with an in-place rebuild? [15:54:03] ^d: better to use the saneifier [15:54:17] <^d> Mmk [15:54:19] its not super quick but it'll detect whatever [16:37:35] csteipp: So right now the Slate skin is pretty much s/Vector/Slate/ everywhere with some small less changes. https://github.com/wikimedia/mediawiki-skins-Slate/commits/master [16:38:10] legoktm: Cool... and who needs it installed on the cluster? [16:38:18] Fiona :) [16:38:42] I think he wants it just on beta right now [16:39:05] I'm actually more worried that it's a clone of vector. More likely that we'll fix something in vector, and foget to update slate too. [16:39:48] Well Vector is largely a clone of MonoBook :P [16:41:28] Proving my point ;) [17:15:26] legoktm: https://gerrit.wikimedia.org/r/#/c/197963/ super tiny change [17:21:34] legoktm: https://gerrit.wikimedia.org/r/#/c/199175/1 & https://gerrit.wikimedia.org/r/#/c/199176/ :) [17:32:32] aspiecat: left a question on the first [17:33:32] <^d> legoktm, aspiecat: Is this stupid? https://gerrit.wikimedia.org/r/#/c/198783/ [17:35:02] ^d: I don't think extension-list has the full list of extensions [17:35:53] <^d> It does not, as I found out [17:36:12] https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/extension-list doesn't have ActiveAbstract [17:36:26] you'd probably just want to use https://github.com/wikimedia/mediawiki-tools-release/blob/master/make-wmf-branch/default.conf directly [17:36:47] <^d> Ugh I don't have that in checkoutMediaWiki though [17:40:11] ^d: what's this for anyways? [17:41:16] aspiecat: Could you take a look at https://gerrit.wikimedia.org/r/#/c/198760/ today for me and Nikerabbit? I think I saw paths in User that would load the prefs from a slave rather than master that may be racing following a save in some use cases. [17:41:32] <^d> legoktm: staging. [17:41:34] it's on the list [17:42:20] and you don't want to use the meta mediawiki/extensions repo that beta uses? [17:44:31] <^d> Why bother cloning and keeping up to date 100+ extensions we're not going to deploy? [17:44:37] <^d> Also, beta does things silly and not like prod [17:44:40] <^d> We want to be like prod [17:45:29] alright :P [17:45:33] aspiecat: thanks [17:53:30] evening bd808 [17:53:40] o/ [17:56:18] <^d> legoktm: On the subject of extensions not in extension-list, https://gerrit.wikimedia.org/r/#/c/198813/ could use a review [17:56:54] +1'd [17:57:05] <^d> thx [18:46:47] legoktm: any other bits on https://gerrit.wikimedia.org/r/#/c/199175/ ? [18:48:54] aspiecat: it feels kinda weird to me to make people explicitly call User::load(), since that's always taken care of implictly usually. [18:53:37] legoktm: wrappers and flags to other places could always be added later...not sure about the best places for that though [18:54:31] it's mostly weird due to the master default behavior, but that's not changing anytime soon [18:55:26] yeah :/ [18:57:54] Nikerabbit: ping? [18:58:19] ori: yes? [18:59:19] Nikerabbit: have you seen Nasir Khan's e-mails on wikitech-l? Do you think you or someone else from the i18n team could reply? Even if no one has the bandwidth to look into it at the moment, it'd be nice to let him know that he's not being ignored, and perhaps even point him at the code that would need to be changed to fix the bug. [19:00:52] He already got answers, AFAICS https://phabricator.wikimedia.org/T58063#1022816 [19:00:58] ori: I didn't realize it had something to do about i18n [19:01:56] Nemo_bis: heh. "Abandon hope." [19:03:18] Yep. Looks like he's an inguaribile ottimista (unhealable optimist) though [19:35:47] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1146304 (10Thompsonbry.systap) Another possibility is using CAS counters (striped atomic counters) to track resources associated with a query and use that to bound memory... [19:42:39] bd808: can I ask you a QR meeting owner question? how many people can I realistically add from RelEng to our QR given everyone else (and hangout/room limits)? [19:42:55] er, how many people can I recommend you add, I guess ;) [19:51:53] greg-g: make your pitch and we'll see what we can do [22:21:52] 6MediaWiki-Core-Team, 6operations, 7Wikimedia-log-errors: rbf1001 and rbf1002 are timing out / dropping clients for Redis - https://phabricator.wikimedia.org/T92591#1146814 (10chasemp) p:5Unbreak!>3High [22:28:32] robla: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_API_Team [22:29:08] palindrome! [22:30:36] 6MediaWiki-Core-Team, 5Patch-For-Review: Figure out a cross-DC strategy for the BloomFilter caches - https://phabricator.wikimedia.org/T93006#1146883 (10aaron) [22:31:05] * Deskana claps in excitment [22:44:44] bd808, is that a virtual team, or all these pplz are going to do teh apiz full time? [22:45:00] full time [22:45:07] w00t [22:45:14] we are breaking up mw-core into a pile of smaller teams [22:45:23] and absorbing multimedia [22:46:00] New teams are: API, Performance, Availability, Search, Security [22:46:11] * bd808 spills all the beans [22:46:23] eh, wassup with multimedia? [22:46:42] 2/3 to API, 1/3 to Perfomance [22:47:01] the team was not getting enough resources to do big things [22:47:07] and mmv be complete? [22:47:37] they haven't been working on mmv for quite a while [22:47:58] <^d> bd808: PSR-7 discussion is pure schadenfreude. [22:48:07] API will inherit responsibility for some uploadwizard backend work [22:48:25] ^d: I stopped looking. Its a madhouse [22:49:24] MaxSem: The big project that will need to be thought about is structured commons [22:49:50] Getting that done right in my opinion will take it being a top priority from WMF [22:50:07] With help from multiple teams [22:50:14] and a strong product owner [22:51:08] just create a service for it! :P [22:51:46] * bd808 rubs magic service fixall on the wound [22:51:53] still bleeding [22:52:26] "Availability"? [22:53:15] as in the measure of reliability; increase and preserve system uptime [22:53:34] * bd808 didn't pick the name [22:54:40] Deskana: There is no etched in stone plan about the long term of that team. In the short term they will be working on the multi-dc project that Aaron started [22:55:09] When that is "complete" they may break up and merge into other teams [22:55:28] That flexibility is nice. [22:55:36] Or by then they may have a strong longer term vision [22:56:44] Basically it's an effort that is related to but distinct from Performance [22:57:46] a manager-speak email is forthcoming with some more context :) [22:58:37] "Make MediaWiki backend failures diminishingly infrequent, and prevent end users from noticing the ones that do by making recovery as easy and automated as possible" [23:01:12] 6MediaWiki-Core-Team, 6Project-Creators: Create MediaWiki-API-Team project - https://phabricator.wikimedia.org/T93823#1146956 (10bd808) 3NEW [23:02:39] 6MediaWiki-Core-Team, 6Project-Creators: Create MediaWiki-API-Team project - https://phabricator.wikimedia.org/T93823#1146977 (10bd808) This team will be starting work on April 1st and I would like to have a place to prioritize their backlog as the acting Product Manager. [23:03:00] can I JFDI ^ [23:03:37] sweet. I has no such powers [23:05:43] 6MediaWiki-Core-Team, 6MediaWiki API Team, 6Project-Creators: Create MediaWiki-API-Team project - https://phabricator.wikimedia.org/T93823#1147010 (10greg) {{done}} [23:06:26] 6MediaWiki-Core-Team, 6MediaWiki-API-Team, 6Project-Creators: Create MediaWiki-API-Team project - https://phabricator.wikimedia.org/T93823#1147019 (10greg) 5Open>3Resolved p:5Triage>3Normal a:3greg [23:11:16] thanks greg-g [23:17:50] 6MediaWiki-Core-Team, 6MediaWiki-API-Team, 10MediaWiki-Authentication-and-authorization, 7Epic: Modernize MediaWiki authentication system - https://phabricator.wikimedia.org/T89459#1147074 (10bd808) [23:19:51] bd808: Can you help me figure out what projects to tag this with? https://phabricator.wikimedia.org/T75086 [23:19:57] 6MediaWiki-Core-Team, 6MediaWiki-API-Team, 10MediaWiki-Authentication-and-authorization, 7Epic: Modernize MediaWiki authentication system - https://phabricator.wikimedia.org/T89459#1147095 (10bd808) [23:20:33] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add bestRank to RDF export - https://phabricator.wikimedia.org/T92990#1147097 (10Smalyshev) 5Open>3Resolved [23:21:32] Deskana: hmm... looks like you have already added quite a list of tags :) [23:21:49] Nobody has been able to reproduce it? [23:22:27] bd808: I experienced the issue myself once, but not intentionally. I have no idea what I did. Unfortunately the app got totally overwritten 5 seconds afterwards because I was running a clean build. [23:22:38] I would guess the "underlying problem" is the mobile app's use of the edit api [23:23:09] so having somebody like legoktm or anomie take a look at the specific code that is calling the api may help [23:24:21] Like supem401 says adding "assert=user" to the api call would help stop bad things from happening [23:24:33] * Deskana looks for the relevant API task [23:24:37] The app would need to add that whenever it thinks the user is authenticated [23:24:57] https://github.com/wikimedia/apps-android-wikipedia/blob/master/wikipedia/src/main/java/org/wikipedia/editing/DoEditTask.java [23:26:04] Now you need to step up in the logic and figure out when and where editToken comes from [23:26:25] https://github.com/wikimedia/apps-android-wikipedia/blob/master/wikipedia/src/main/java/org/wikipedia/editing/FetchEditTokenTask.java [23:26:33] Do those tokens expire? [23:26:38] asserting that the app thinks the user is logged in is not a stupid hack [23:26:45] yeah. On every use I think [23:26:49] Apparently it's being stored... [23:27:35] * Deskana scratches his head [23:27:49] Do you think Brad or Kunal could spare some time to help us debug this? [23:28:01] Perhaps we're just doing something stupid and we don't know. [23:28:31] Yeah. Let's see if we can get a consultation from one of them [23:28:53] How OMG!!111! urgent is this? [23:29:20] I'm going with "normal". [23:29:44] Is that helpful enough or do you want more granularity than that? [23:35:58] Deskana: "normal" works. I'll see if I can find some interest to help. It will likely require one of your coders to walk through what the app is doing and why. Seems like the exact sort of thing the new team should be helping with though :) [23:36:27] bd808: Dmitry Brant will be the point engineer from Apps for that. [23:36:45] Thanks! [23:47:20] Deskana: "To edit a page, an edit token is required. This token is the same for all pages, but changes at every login." -- so it expires but only when the session expires [23:47:55] What's a session in this context? [23:48:06] I would assume browser session... but the client isn't a browser. [23:48:07] PHP backend session I suppose [23:48:26] Hmm. I wonder if that's why this seems to happen somewhat randomly. [23:48:35] possibly [23:49:14] probably the right thing to do is add the assert and handle the error by getting a new token and retrying when it happens [23:49:39] If we add the assert and everything is fine except the token is wrong, will the API tell us so? [23:49:47] yup [23:49:48] I'm hoping that it can differentiate between that and "wrong password" or something [23:50:00] Ah, interesting. I like this solution. [23:50:01] it has a distinct error code [23:50:05] Fantastic. [23:50:28] You, sir, are a gentleman and a scholar. [23:50:45] We lose nothing by putting that in. Then we'll just hope that stops the errors. [23:50:49] heh. let's not get crazy [23:50:57] https://www.mediawiki.org/wiki/API:Edit [23:51:21] that's where I read the bit about per-login tokens