[00:02:23] csteipp, is there a task? [00:02:48] AaronSchulz: https://phabricator.wikimedia.org/T90300#1277990 [00:15:30] AaronSchulz: I'm heading home in a few minutes... Specific questions in the last comment on that task. [00:16:44] * AaronSchulz will try to look [00:23:03] there's a steady stream of InvalidArgumentException from line 240 of /srv/mediawiki/php-1.26wmf6/includes/Message.php: $key must be a string or an array (predating SWAT). What's that about? [00:24:14] ori, is the bad title bug? [00:24:31] yes, it's coming from MalformedTitleException [00:24:33] is that known? [00:25:22] looks related to I43d988602b847b67a3cf0aa84e271a0b5bd9adae [00:26:06] https://phabricator.wikimedia.org/T99818 ? [00:29:23] yeah, that's it [00:30:23] AaronSchulz: save time spiked: http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1431990359.151&target=mw.performance.save.median [00:32:21] could just be spikey [00:32:25] * ori waits a few more minutes [04:43:16] AaronSchulz: some of these in the logs: May 21 04:42:06 mw1192: #012Notice: JobQueueGroup::__destruct: 1 buffered job(s) never inserted. in /srv/mediawiki/php-1.26wmf6/includes/jobqueue/JobQueueGroup.php on line 419 [04:44:10] ori: https://gerrit.wikimedia.org/r/212485 is the final fix for it [04:44:29] nice [04:44:36] that's long overdue for other reasons too [05:08:12] ori, too bad warnings didn't have a URL [05:08:31] could we register an error handler to tack that on? [05:08:50] probably [05:20:14] AaronSchulz: meanwhile, saves got faster with no $wgDiff: http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1432183268.056&target=mw.performance.save.median&from=-1hour [05:20:30] i first deployed that at 4:40 as a local hack after trying it on a few hosts [05:21:18] the spike is the TC cache filling up and a bunch of HHVM hosts restarting [05:22:04] yeah, would be nice if this was less noisy [05:23:45] AaronSchulz: https://performance.wikimedia.org/ is clearer (bottom graph) [05:25:07] saves are the fastest they've been since we started measuring this particular metric (february) [05:25:14] as of right now, i mean [05:25:40] probably the fastest they've been for several years [05:26:10] s/for/in/ [05:27:13] that's about 90% your work, you should feel pretty good about that :P [05:30:31] ori, https://gerrit.wikimedia.org/r/#/c/211888/ is also incoming [05:34:45] is that no longer a WIP? [05:38:54] legoktm, you can look at it :) [05:39:21] handling the mPrepared stuff is a bit tricky since in theory the same WikiPage object could have multiple edit calls in a request [05:39:39] * AaronSchulz wishes he could just kill the user newtalk stuff btw [05:40:01] legoktm, can't we just bundle flow? :) [05:40:24] you mean echo? not yet [05:40:31] we are really a bad a killing UI stuff [05:40:50] * AaronSchulz wonders wonders what other top 10 sites are that bad [05:41:05] it's my goal to have it merged in core properly by the end of the year, but it needs a lot of cleanup [05:42:21] legoktm, https://phabricator.wikimedia.org/T94448 [05:42:58] it's convenient how you happen to be working on much of my external blockers [05:43:24] :/ [05:43:26] that's some weird thing for Flow integration I think [05:43:42] * AaronSchulz needs to pester aude about https://phabricator.wikimedia.org/T97335 [05:43:46] it checks if you've visited the page, and marks the notification as half-read [05:45:15] AaronSchulz: I'm wondering if some data updates will affect how the page renders in the next request...especially Wikibase's [05:52:02] legoktm, they can take a look [15:43:12] anomie: https://gerrit.wikimedia.org/r/#/c/210746/2/includes/api/ApiQueryBase.php,unified what's the 'x' for? [16:28:43] legoktm: http://stackoverflow.com/q/30326849/323407 sounds like it could be some sort of rename/merge bug [16:29:50] o.o [16:32:31] usercontribs is the wrong one [16:37:15] tgr: yeah looks like it http://fpaste.org/224331/22622514/raw/ the db is wrong [16:40:02] tgr: could you file a bug for this? [17:26:13] legoktm: https://phabricator.wikimedia.org/T99929 [17:26:18] thanks [17:38:34] Gosh, getting really close to https://phabricator.wikimedia.org/T100000. [17:40:19] inb4 "Release MediaWiki 3.0" [17:46:05] :-) [17:46:41] Let's just rebadge MW 1.26 as 2.0. There's enough breaking changes in it thanks to legoktm's extension registration stuff. :-) [17:47:07] nope! no breaking changes! [17:47:12] Though semver for MW might be hard to make. [17:47:25] unless you need to set $wgExtensionDirectory [17:47:37] That's a breaking change, then. :-) [17:47:40] but we shouldn't have broken anything [17:47:53] well, people shouldn't put their extensions in non-standard places :P [17:48:07] Indeed. [18:03:36] legoktm, to which definition of standard? FHS, for example, says everything should be dispersed all around [18:04:59] OuKB: the "MediaWiki standard" which is follow whatever Wikimedia does [18:55:02] legoktm: The 'x' is for the same reason as in the method above: it keeps Title methods from trimming trailing whitespace that's insignificant in full titles but is significant when you're looking for page prefixes. [18:55:21] right [18:55:22] ok