[00:01:33] 6MediaWiki-API-Team, 6Availability-Team, 10MediaWiki-JobQueue, 10SUL-Finalization, 5Patch-For-Review: Create separate job loop for LocalRenameUserJob - https://phabricator.wikimedia.org/T87397#1208484 (10Legoktm) 5Open>3Resolved [00:16:53] blazecat: if you have some time, a review of https://gerrit.wikimedia.org/r/#/c/204073/ would also be appreciated :) [00:20:28] legoktm: are you actually using the session or just the ip/user stuff? [01:06:46] ^d: https://gerrit.wikimedia.org/r/#/c/204208/ [03:37:42] blazecat: just the IP and user agent [03:44:55] thanks [05:41:29] hi is there way to find out which error caused https://phabricator.wikimedia.org/T94402#1207765 ? [05:41:41] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1208703 (10tstarling) >>! In T961#1159155, @Keegan wrote: > The code, as written, works... [05:42:18] Nikerabbit: 2015-04-14 20:34:58 mw1195 ukwiki: [21e87513] /w/api.php?action=query&format=json&list=contenttranslation&translationid=34778 ErrorException from line 262 of /srv/mediawiki/php-1.25wmf24/includes/exception/MWExceptionHandler.php: Fatal Error: request has exceeded memory limit [05:42:37] fatal.log on fluorine [05:43:38] ori: thanks [05:44:12] no problem [05:44:34] now the mysteri is what is causing it to exceed memory limit :( [05:45:34] can you reproduce this locally? [05:45:58] ori: maybe if I copy that draft to local instance [05:46:23] Who can access the draft? [05:46:47] nobody, evidently ;) [05:46:52] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1208704 (10Keegan) >>! In T961#1208703, @tstarling wrote: >>>! In T961#1159155, @Keegan... [05:47:26] select length(draft_content) from cx_drafts where draft_id = '34778'; [05:47:33] 302576 [05:49:17] don't forget about the wikimedia debug extension [05:49:24] I wonder if $result->addValue() performs some normalisation which doesn't like large strings [05:49:34] you can use it to make all your requests go to mw1017 [05:49:42] and you can hack things there [05:49:50] here's how to get xhprof profiling: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/StartProfiler.php#L21-28 [05:51:24] hmm [05:51:55] the main problem is that the drafts are private to the owner [05:52:28] is it yours? [05:53:29] If not, have you done memory profiling of the content translation stuff at all? You may be able to identify a memory consumption problem with other inputs -- there's nothing necessarily special about this particular example. [05:53:40] a grand total of 33 users are going to be renamed on beta labs. [05:54:04] legoktm: o/ [05:54:28] ori: hmm yes I could create my own draft of similar size [05:55:01] TimStarling: The best way that I can describe the big problem with global user merge is comparing it to merging page histories: often, when you go back to undelete all the content and complete the merge, you find the content you deleted to make the merge happen completely gone [05:55:23] (er, that doesn't happen, that would be the bug if it were page histories) [05:55:55] legoktm: does that sound about right? [05:56:00] Nikerabbit: maybe one of these? https://en.wikipedia.org/wiki/Special:LongPages [05:58:01] so the content is all gone except that it isn't all gone? [05:58:15] but something approximately like the content being gone occurs? [05:58:43] * ori squints and rubs his temples. [05:59:40] TimStarling: Yes. Things go poof :) [05:59:57] this is not as specific as I was hoping [06:00:34] Yes, that's the problem indeed. It breaks in most any variation of attribution/account deletion [06:01:38] When leaving the move trail behind, either the edit gets lost, the attribution gets lost, or the move itself gets lost [06:01:59] you mean when moving user pages? [06:02:19] Conributions [06:02:23] * Nemo_bis waiting for https://uk.wikipedia.org/w/index.php?title=%D0%A1%D0%BF%D0%B5%D1%86%D1%96%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0:%D0%9F%D0%B5%D1%80%D0%B5%D0%BA%D0%BB%D0%B0%D0%B4_%D0%B2%D0%BC%D1%96%D1%81%D1%82%D1%83&page=Greek+government-debt+crisis&from=en&to=uk&targettitle=Greek_government-debt_crisis to load [06:02:27] *contributions [06:02:54] Nemo_bis: it's a big crisis [06:05:10] TimStarling: That might help specify the problem, it's with merging the actual contribution (edit/php array/whathaveyou) and keeping everything around it congruous, from the edit actually appearing in the log properly to even showing up at all, to the original account no longer being tied to the rename to make appropriate attribution. [06:05:53] Keegan: right now the script is just logging on the local wiki where the rename is made, should there be an entry in meta's global rename log as well? [06:06:18] legoktm: Yes, please :) [06:06:24] are you sure it locally logs? [06:06:52] LocalUserMergeJob passes a UserMergeNoopLogger to MergeUser [06:07:23] If you're asking me, I don't know :) legoktm? [06:07:41] TimStarling: oh, I'm talking about the forceRenameUsers.php script for tomorrow, which has RenameuserSQL add log entries [06:08:19] by "actual contribution (edit/php array/whathaveyou)" I think you mean revision [06:08:20] TimStarling: we need to get rid of the NoopLogger thing and pass the normal logger for that, the global user merge code has fallen a little behind global rename [06:08:37] at that time we didn't want local logs, but we do now [06:09:01] by "edit actually appearing in the log" maybe you mean "revision actually appearing in the page history" [06:09:27] or maybe you mean the user contributions page, which would make more sense [06:10:24] TimStarling: I believe the third, yes. [06:11:42] ori: but a great bug finder ;) https://phabricator.wikimedia.org/T94402#1208726 [06:11:43] has this happened on the live site? or just in beta? [06:11:47] beta [06:11:52] ^ [06:11:57] it hasn't been turned on in production yet [06:12:49] does the job succeed? or is there an exception? [06:14:23] can I see the state of the database after this issue has occurred? [06:16:22] something in here maybe? http://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3ALog&type=gblrename&user=&page=&year=&month=-1&tagfilter= [06:16:44] do you know which of those failed? [06:17:40] I don't recall, give me a moment and I can produce a failure [06:18:40] er wait [06:18:54] I'm nearly done finalizing SUL, break stuff after that [06:21:31] legoktm: ack, too late, just three accounts :( [06:21:34] http://meta.wikimedia.beta.wmflabs.org/wiki/Special:CentralAuth/Test_8 [06:21:58] Keegan: well, I finished :P [06:22:19] TimStarling: That was following the second scenario of my task comment. Create three accounts, make one edit with the last, merge to the first [06:25:37] if someone wants to do some quick reviews on minor changes to the SULF script: https://gerrit.wikimedia.org/r/#/q/owner:%22Legoktm+%253Clegoktm.wikipedia%2540gmail.com%253E%22+topic:fru,n,z [06:31:28] 6MediaWiki-API-Team, 10Beta-Cluster, 10SUL-Finalization: Finalize SUL on beta cluster - https://phabricator.wikimedia.org/T96075#1208729 (10Legoktm) 5Open>3Resolved The following 13 users were renamed: ``` mysql> select * from users_to_rename; +--------+-------------------------------+------------------+... [06:33:04] Keegan: do you see an exception message at that URL? [06:33:29] I do, would you like me to email it? [06:34:23] Or put on Phabricator [06:35:26] no [07:07:32] legoktm: peace out brussel sprout, tomorrow we make something out of nothing :) [07:13:21] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1208787 (10tstarling) The code is not too bad. The LocalUserMergeJob potentially has a... [13:22:31] twentyafterfour: If you think of it, please ping me when you cut the 1.26wmf2 branch. There's a patch I'm ready to merge, but it's interesting enough that I'd rather it not be merged at the last minute. [13:23:30] anomie: would it be helpful if I cut the branch early? [13:24:05] twentyafterfour: You can if you want, but the normal time is well within my working hours. [13:33:33] <^d> legoktm: All 3 merged [13:44:43] twentyafterfour: we are updating wikidata [13:44:59] cut the branch early is ok, but probably need another hour [13:45:08] or can update submodule [13:45:57] aude: I'm in no hurry - I usually don't cut the branch until about 9:30 pacific (almost 3 hours from now) [13:46:17] ok [14:03:23] wait, twentyafterfour is awake already or still? :) [14:04:19] <_joe_> swtaarrs: hey, the API version was removed from the output of hhvm --version, but I used it to verify that extensions were compatible with the installed package. What should I use instead? It was introduced here: https://github.com/facebook/hhvm/pull/3322 and removed here: https://github.com/facebook/hhvm/commit/573d6fc0d2745e96ee9775f31dc993919086fc7a [14:08:00] greg-g: already... pulling an all-nighter on Tuseday-Wednesday would be decidedly unwise [14:09:03] oh hai, greg, I saw you on the youtubes: https://www.youtube.com/watch?v=Nffzkkdq7GM [14:10:13] :) [14:10:36] that was a fun conf (and the year before) [14:10:46] this year it's somewhere in Europe, I'm not going unfortunately [14:50:05] ^d: thanks! [14:50:11] <^d> yw [15:03:11] <^d> bd808: I know it's a rabbit hole, but...we really need to find someone with the cycles to fix RequestContext::getLanguage() recursion. [15:03:21] <^d> It's basically the #1 error these days with all our error squashing [15:06:58] <^d> legoktm: 20 error: Argument 1 passed to CentralAuthUser::getInstance() must be an instance of User, bool given in /srv/mediawiki/php-1.25wmf24/extensions/CentralAuth/includes/CentralAuthUser.php on line 77 [15:08:30] ^d: and I'm guessing no stacktrace? [15:08:46] hmm, it's on login? [15:08:53] <^d> No idea :D [15:08:55] <^d> hhvm.log [15:09:02] fatal.log has the request parameters :) [15:09:42] <^d> yep, login [15:10:02] <^d> 2015-04-15 07:08:41 mw1044 jawiki: [39d2dcd8] /w/index.php?title=%E7%89%B9%E5%88%A5:%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3&action=submitlogin&type=login&returnto=%E5%B9%B3%E5%B0%86%E9%96%80 ErrorException from line 262 of /srv/mediawiki/php-1.25wmf24/includes/exception/MWExceptionHandler.php: Fatal Error: Argument 1 passed to CentralAuthUser::getInstance() must be an instance of User, bool given [15:10:22] bd808: ^ on a random guess I think it's the SUL login using old name stuff? that's the only new login related code we've deployed I think [15:11:05] the onLoginUserMigrated hook? [15:11:47] $u = User::newFromName( $this->mUsername ); [15:11:51] if ( !Hooks::run( 'LoginUserMigrated', array( $u, &$msg ) ) ) { [15:11:53] yep [15:17:31] <^d> Want me to file something in Phab for this? [15:17:51] <^d> Oh you did, got it [15:18:28] ^d: https://gerrit.wikimedia.org/r/204278 [15:18:38] <^d> looking [15:19:35] <^d> Yeah that'll do it for a fix [15:20:42] <^d> We could swat that to 1.26wmf1 since the old branch dies today anyway [15:24:08] ^d: sounds good to me, could you take care of that? [15:24:18] <^d> yeah I got it [15:30:16] <^d> wow my clone for wmf branch work was hella out of date [16:08:34] ^d: first time in a while? [16:08:49] <^d> No just like 2 branches old :p [16:08:54] <^d> That's too old [16:09:11] :) [16:09:53] <^d> Also, I'm running late, see ^^ re: centralauth [16:10:12] * greg-g nods [16:10:15] s'ok [16:14:31] _joe_: the API version was a complete lie, and we don't yet have anything to replace it :-/ [16:14:35] it wasn't safe to rely on it [16:14:52] <_joe_> swtaarrs: gee, ok [16:14:55] but we're working on a formal extension API [16:15:03] that will have all sorts of good promises about stability [16:15:07] <_joe_> but we external packagers need something :) [16:15:10] heh [16:15:25] <_joe_> should I just use the HHVM major.minor version? [16:15:42] <_joe_> so expect ABI compatibility along the 3.6 run? [16:15:48] what does this verification? in theory you should be rebuilding extensions any time you rebuild hhvm [16:15:53] 6MediaWiki-API-Team, 10SUL-Finalization, 5Patch-For-Review: Check for empty global accounts - https://phabricator.wikimedia.org/T93167#1209549 (10Legoktm) 5Open>3Resolved 3675 global accounts were deleted, and 270 local accounts are now attached to a global. [16:16:12] <_joe_> swtaarrs: well, it's used for defining relative dependencies of the packages [16:16:28] s/verification/verify/ [16:16:29] hm ok [16:16:38] so it goes in the package version number? [16:17:34] <_joe_> it goes into Provides: hhvm-api-$version in the hhvm package, and in Requires: hhvm-api-$version in the extensions [16:18:05] getting ready to cut the new branch... aude: I merged your patch for the new wikidata branch [16:18:05] ahh ok [16:18:05] twentyafterfour: thanks [16:18:05] <_joe_> swtaarrs: this helps automating updates [16:18:14] <_joe_> swtaarrs: for now I'll keep using it and testing any update of mine [16:18:18] _joe_: I'd say use the full version number. it's likely that 3.6.x releases won't make any ABI changes but I wouldn't depend on that [16:18:28] <_joe_> swtaarrs: ok [16:18:43] <_joe_> ok that's actually even better :) [16:18:49] <_joe_> thanks! [16:18:53] np [16:19:30] and if you ever need to do you own builds in between point releases you can poke me to look at the patch [16:19:36] to see if it would cause ABI changes [16:19:52] better safe than sorry in general, but it can be a pretty easy call for really small changes [16:23:22] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OOUI-ify the management interfaces for OAuth - https://phabricator.wikimedia.org/T96154#1209567 (10MarkTraceur) 3NEW a:3MarkTraceur [16:26:41] <^d> blazecat: https://gerrit.wikimedia.org/r/#/c/204290/, trivial [16:27:01] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth authorize interface shouldn't be a modal dialog - https://phabricator.wikimedia.org/T96156#1209597 (10MarkTraceur) 3NEW a:3MarkTraceur [16:30:48] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Add a separate queue for approval, and a button to submit consumers to it - https://phabricator.wikimedia.org/T96157#1209611 (10MarkTraceur) 3NEW [16:32:11] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Add a "not X? log in with a different username" bit to the authorize form - https://phabricator.wikimedia.org/T96158#1209622 (10MarkTraceur) 3NEW [16:32:32] Gonna be a productive bloody day [16:33:46] Oh, gods, it uses HTMLForm too [16:35:36] yeah? at least for you [16:35:58] greg-g: I retract my earlier statement. [16:36:08] take a peek at my calendar [16:36:15] I will probably wind up working on making HTMLForm use OOUI, which means nothing I do today will matter until at least next month. [16:36:37] > Beer? [16:36:38] Love it. [16:36:48] greg-g: Oh, you're coming in today! Woot! [16:37:19] greg-g: But also, my condolences for your schedule [16:37:28] marktraceur: yep! I'm on 5 right now, in the platform/everything QR [16:37:49] I'll see you at the talk later [16:38:10] * greg-g nods [16:39:44] I was going to say "come say hi when you're done" but lol, look at that, another meeting. :P [16:43:00] <^d> legoktm: you're all live. [16:43:05] <^d> thx for quick fix [16:45:05] :) ty [16:45:54] ^d: that said...I'm going to probably spam the logs with a bunch of out of sync db transaction warnings in a few minutes due to a script [16:46:19] <^d> One error two error red errors blue errors [16:46:27] Errors that climb on rocks [16:47:07] errors that wear green socks [17:15:53] 6MediaWiki-API-Team, 10MediaWiki-HTMLForm, 10UI-Standardization: Implement OOUI "display format" in MediaWiki's HTMLForm - https://phabricator.wikimedia.org/T85291#1209743 (10MarkTraceur) [17:16:17] 6MediaWiki-API-Team, 10MediaWiki-HTMLForm, 10UI-Standardization: Implement OOUI "display format" in MediaWiki's HTMLForm - https://phabricator.wikimedia.org/T85291#943417 (10MarkTraceur) I wouldn't mind working on this, I could use a bit of guidance from someone with HTMLForm experience and someone with OOUI... [17:16:52] Geez, that sent notifications everywhere. [17:18:13] marktraceur: Don't add it to so many diverse projects, then. ;-) [17:19:11] wow [17:19:13] I hate PHP [17:19:19] James_F: It's just three! [17:19:22] my script thinks its over because the user has a name of '0' [17:19:46] James_F: But now I'm thinking "How many projects would I need to add to send a notification to *every* channel" [17:19:50] marktraceur: Good thing you didn't tag it with OOjs UI – that'd have added a fourth. [17:19:53] legoktm: Fuuuun. [17:19:55] legoktm: Ah'hahaha [17:20:06] is [17:20:17] while ( strlen($line = trim( fgets( $file ) ) ) ) { ...} [17:20:18] valid? [17:20:22] James_F: That's why it didn't show up in VE, gosh. That's the group I actually need to bother. [17:20:26] marktraceur: :-D [17:21:01] apparently [17:22:15] 6MediaWiki-API-Team, 6CA-team, 10MediaWiki-API, 10MediaWiki-User-login-and-signup, and 4 others: App says I'm logged in, but edits are saved from IP - https://phabricator.wikimedia.org/T75086#1209769 (10bearND) 5Resolved>3Open Reopening since it's probably not fixed on iOS yet. [17:22:39] ^d: is https://gerrit.wikimedia.org/r/204296 sane? [17:24:09] thanks blazecat [17:54:30] 6MediaWiki-API-Team, 10MediaWiki-General-or-Unknown, 10MediaWiki-extensions-CentralAuth: Re-evaluate location of LoginUserMigrated hook - https://phabricator.wikimedia.org/T96174#1209895 (10Legoktm) 3NEW [18:23:47] Keegan: https://test.wikidata.org/wiki/Special:RecentChanges [18:28:42] MMkay [18:34:35] Keegan: the SUL you have been renamed page doesn't have a link to GlobalRenameRequest? [18:35:09] The post log-in one? [18:35:13] I thought it did... [18:35:16] * Keegan checks [18:35:29] Shit. [18:35:32] Shit shit shit shit. [18:35:42] Keegan: https://i.imgur.com/kIpqjTe.png [18:36:25] Okay so that's not going to work [18:36:43] I *just* reviewed all this last week. [18:38:34] I guess it needs "To request a different account name, visit [[Special:GlobalRenameRequest]]. Thank you for participating..." [18:39:03] http://fpaste.org/211381/29123107/raw/ is the current message [18:39:19] do you want to edit it and I can update the repo and deploy [18:40:23] Yes [18:42:45] legoktm: http://fpaste.org/211384/42912335/raw/ [18:47:16] Keegan: +1 on https://gerrit.wikimedia.org/r/#/c/204313/ ? [18:49:47] I was too slow, it seems [18:57:08] Keegan: ok, so twentyafterfour is going to deploy it with the normal train, which is probably going to take an hour ish....we should also get translators to update the localized versions [18:58:08] Okay. Do you have any clue where this is going to live on translatewiki? [18:59:51] Nikerabbit: how long will it take for https://gerrit.wikimedia.org/r/204313 to show up on twn? [19:01:07] It depends on whether Raymond already went to sleep ;) [19:01:28] legoktm: let me check, if Raymond did his updates already I can ppull it now [19:01:38] thanks [19:01:47] Not yet https://gerrit.wikimedia.org/r/#/c/204132/ [19:02:02] So it will probably be sync'ed in a couple hours by him [19:03:06] Nemo_bis: as far as I can see he already did imports [19:04:06] But 5 h ago, he usually does multiple [19:04:26] If you can sync yourself that doesn't harm; I can do the special page part :) [19:05:16] imported [19:05:36] Thanks Nikerabbit [19:05:51] thanks Nikerabbit! [19:05:54] legoktm: do note, that unless you backport this to the older wmf branch, LU is not supposed to pick up newer translations [19:06:03] Ah you already did Special:ManageMessageGroups too [19:06:10] Nikerabbit: it's been backported to 1.26wmf1 and 2 [19:06:17] legoktm: than you are good [19:06:21] awesome :) [19:06:22] Keegan: ^ [19:06:47] Thanks the third :) [19:09:20] Nemo_bis: so where does this text live on translatewiki? [19:11:27] legoktm: Re 204312, I was hoping tto would double-check that I got his handle right before it got merged ;) [19:12:15] Keegan: https://translatewiki.net/wiki/MediaWiki:Wikimedia-sulrenamewarning-usenew/en but as usual you can link the extension messages as a whole [19:12:32] Thanks [19:12:52] anomie: ah right, removed +2 for now [19:18:17] The qunit failures are only semi-bogus. Something changed in MediaWiki core these past few days that makes localisation cache incredibly slow [19:18:22] Causing tests to time out [19:18:54] I would not feel comfortable deploying anything, but oh well. I have no clue how to debug that right now. [19:36:29] swtaarrs: hey, yt? [20:21:47] <^d> csteipp: Since the patch linked from T88964 is already merged and it's not a bundled extension, could we close it? [20:23:26] <^d> (Also I'm not sure T91850 is a security bug blocking release of 1.24.x, moreso just a "heh yeah we should do that...") [20:25:24] ^d: Yeah, I would mention T88964 in the release announcement, since we have a crazy number of SMW wikis [20:26:01] T91850 I'd like to get a patch for [20:26:13] Not a blocker though if we can't get a patch ready. [20:26:22] <^d> I wouldn't mind seeing it block REL1_25 though [20:29:54] yeah, I assumed 1.24.3 would be the last sec release before 1.25. [20:31:17] <^d> Prior to, yeah [20:31:26] <^d> Its eol isn't until November though [20:31:51] ori: hey. I was at lunch [21:01:36] Keegan|Away: https://test2.wikipedia.org/w/index.php?title=Special:RecentChanges&hidebots=0 [21:11:26] legoktm, ^d: Who considers whether something should be backported to 1.25 at this point? 188543/203061/204311 would be nice to go with 181958. [21:15:00] <^d> Ask the release manager! [21:15:02] <^d> Oh wait... [21:15:39] ^d: Is that "oh wait" because we don't have one, or because it's you? [21:15:48] <^d> Because it's me :D [21:16:02] Oh, good! I found the right person (: [21:16:52] <^d> Yeah I'd +2 those for rel1_25 [21:17:08] <^d> Cherry pick them over and slap me on the review list [21:28:20] anomie: if it's being backported to 1.25, it should be removed from the 1.26 release notes [21:28:32] legoktm: Working on a patch for that now [21:32:03] bd808: Is there a person in UX who is working on OAuth stuff? [21:32:38] csteipp: What do you need for it? We don't have a dedicated person but I could maybe go annoy someone until they help [21:32:43] blazecat: FYI: People would like to have you in #wikimedia-office [21:33:02] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Add warning for user on /authorize about privacy policy - https://phabricator.wikimedia.org/T64687#1210569 (10csteipp) >>! In T64687#1208264, @MarkTraceur wrote: > @csteipp my solution to T59457 actually means we can't add this to an existing message, because... [21:33:10] bd808: ^ [21:33:27] Ah. [21:34:30] Actually, with T64686, that doesn't won't look too horrible. [21:34:37] legoktm: how far out are we, do you think? [21:34:51] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7Design: Add warning for user on /authorize about privacy policy - https://phabricator.wikimedia.org/T64687#1210574 (10MarkTraceur) [21:41:06] Keegan: debugging an issue on testwiki right now [21:41:17] see -stewards [21:41:29] K, thanks :) [21:42:27] 6MediaWiki-API-Team, 10MediaWiki-API, 5MW-1.25-release, 5Patch-For-Review: Clean up ApiResult and ApiFormatXml, create new formatversion - https://phabricator.wikimedia.org/T76728#1210592 (10Anomie) [21:42:42] 6MediaWiki-API-Team, 10MediaWiki-API, 5MW-1.25-release, 5Patch-For-Review: Clean up ApiResult and ApiFormatXml, create new formatversion - https://phabricator.wikimedia.org/T76728#819003 (10Anomie) [21:48:04] anomie: FYI, qunit time out is T95971. Working on it at the moment. Strange race condition where api.php times out for 30 seconds. Could be mysql related. [22:05:53] blazecat: is there an easy way to remove jobs that failed and are going to be retried? if it's not easy they'll just fail 2 more times and that's ok