[19:01:47] anomie: If you get bored, it would be awesome to have somebody who actually knows lua look at https://wikitech.wikimedia.org/wiki/Module:SAL and see if it can be sped up a bit more. [19:02:02] * anomie looks [19:02:12] It's used in a new template that wraps each SAL entry so it gets run a zillion times per page [19:13:55] * anomie grumbles about Scribunto's profiling stuff being missing from the "parser profiling data" section [19:14:41] anomie: is that something we messed up with the profiler and logging changes a couple of years ago? [19:14:54] tgr: is https://gerrit.wikimedia.org/r/#/c/321705 ready to merge? [19:16:43] bd808: hm, probably not [19:17:06] there will be some sort of "force email auth on everyone flag" which we probably want to flip in the vagrant role [19:17:23] k. let me know when to +2 or JFDI when you are ready [19:17:29] didn't think that one through [19:19:48] anomie: i think i recently fixed that by reverting some broken changes to parser limit report in core. [19:41:58] bd808: I can't tell if the stuff I'm trying is making it any faster or not. [19:44:04] anomie: ok. the main SAL is taking ~10s to render after an edit, which is down from ~27s before I archived half the page and took out 3 regex scans [19:44:20] if it stays around that I suppose it's fine [19:46:11] If Scribunto's profiling comes back with wmf.3, remind me and I'll take another look. [19:49:03] https://gerrit.wikimedia.org/r/#/c/320461/ it is indeed in wmf.3 [20:12:25] Sigh. More than half of the hits for T145649 in the past 30 days are due to a three copies of some "adminwatch.js" user script on Commons being used by a handful of users. [20:12:26] T145649: Deprecate and remove use of API action=purge with GET requests - https://phabricator.wikimedia.org/T145649 [20:34:54] ostriches: do you want to +2 https://gerrit.wikimedia.org/r/321716 too? [20:37:06] James_F got it, thanks [22:24:18] tgr, anomie: https://gerrit.wikimedia.org/r/#/c/321798/ is a fix for something that is probably making it hard to find throttler logs in kibana. They don't show up under dashboards that are filtering for 'type:mediawiki' [22:32:34] [https://www.mediawiki.org/wiki/Extension:EmailAuth EmailAuth] can request email-based verification on login. [22:33:19] (linux clipboards + a faulty mouse button is a bad combination) [22:34:21] it would be really nice to prefix the log context somehow, maybe in a log processor in MediaWiki [22:34:44] or at least have a blacklist [22:34:58] (which I think we do but only 'message' is on it) [22:53:31] tgr: prefixing is easy. I actually disabled the default prefix in our config [22:54:25] a c_ prefix would not hurt IMO [22:54:34] https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/logging.php#L156 [22:54:41] The '' there is the prexif [22:54:46] *prefix [22:55:54] changing it will only break all dashboards that are using context data. Probably not too hard to fix up after [22:56:22] or we could blacklist the common logstash format keys [22:57:41] this is one of those "never occurred to me" problems because of my familiarity with the log record standard [23:26:25] bd808: let's go with blacklisting, that seems less disruptive [23:26:34] do you have a list? [23:26:56] let me find it... [23:29:56] tgr: looks like a pretty short list -- https://github.com/Seldaek/monolog/blob/master/src/Monolog/Formatter/LogstashFormatter.php#L71-L88 [23:30:32] plus all the stuff in WikiProcessor I suppose? [23:30:39] datetime, message, channel, level_name, type, level, host [23:31:27] yeah, the wikiprocessor ones would be good to protect too [23:34:02] the test failure on https://gerrit.wikimedia.org/r/#/c/321798/ looks like some kind of race condition?