[15:26:08] bd808: I'll probably be 10-15 minutes late for our meeting. [15:33:51] anomie: ok. I'll be in the hangout, so yell to get my attention :) [16:10:51] Notice: Undefined index: rc_logid in /srv/mediawiki/php-1.31.0-wmf.6/includes/changes/RecentChange.php on line 393 [16:10:55] I could've sworn we fixed that [18:47:24] Why does [[File:poweredby_mediawiki_88x31.png]] display a file from resources/assets? [18:50:11] Reedy: I can't seem to reproduce that. [18:50:17] I can on my vagrant wiki [18:51:22] Only that size file.. [18:51:47] There's no uploads on the wiki [18:52:14] OH [18:52:16] instant commons [18:52:45] duh [18:52:50] https://commons.wikimedia.org/wiki/File:Poweredby_mediawiki_88x31.png [18:53:05] So it wasn't actually having resources/assets in the URL? [18:53:13] Nope [18:53:15] Just looked like it [19:47:22] Reedy: Maybe we should implement EvilLocalFileRepo extends LocalRepo { .... if ( lcfirst($filename) == 'poweredby_mediawiki_88x31.png' ) { readfile("$IP/resources/assets/$filename"); } [19:48:57] * Reedy slaps Krinkle [20:07:13] https://gerrit.wikimedia.org/r/388576 easy :) [20:11:53] no_justification: the "params" collection might cause problems on the elasticsearch side [20:12:29] moden es does this thing where it collapses all the fields with the same name into the same index [20:12:41] so collections can be problematic [20:15:07] Oh shit, I meant to keep that Json encode call [20:15:10] Fixing! [20:17:56] bd808: Amended. Good catch! [20:18:26] I was just helping fix yet another version of T150106 on Tuesday ;) [20:18:26] T150106: Type collisions in log events causing indexing failures in ELK Elasticsearch - https://phabricator.wikimedia.org/T150106 [20:20:01] no_justification: you are on quite a structured logging roll. :) [20:20:30] Slow week with the train, so using the time to make my logstash dashboards more useful [20:20:57] So this is totally self serving 😂 [20:21:29] every year I think about making log conversion a GCI task, but I don't think I have the bandwidth for the code review [20:21:51] most of them are pretty mindless to do though [20:21:58] just takes someone caring [20:22:05] I just keep knocking them out as I see them [20:22:10] The one that *really* bugs me is exceptions [20:22:43] We clearly can inject parameters to the log entry (cf: {exception_id}), but we don't have a way for the /thrower/ to add them [20:23:00] Also doesn't help that MWException is a shitty base class that we don't always even subclass. [20:23:01] hmmm [20:23:08] Like, what if you use \RuntimeException? [20:23:17] Should we have a lightweight wrapper around all built-in exceptions? [20:23:19] * no_justification shrugs [20:23:32] Aaron and I actually did some work to kill use of MWException [20:23:51] <3 [20:23:59] He made an exception renderer instead [20:24:07] which is a much better idea [20:24:14] that was ... a while ago [20:26:01] But yeah, MWExceptionRenderer can do the things for 'normal' exceptions [20:26:23] it looks liek we stopped short of making MWException use the renderer :/ [20:26:58] that was part of factoring something (db stuff?) into libs [20:52:14] no_justification: you just need an exception subclass which is created with the PSR parametrized syntax, creates $message by doing the replacements, and is queryable by MWExceptionHandler via some interface [20:53:06] I want to do that as part of the MWExceptionHandler refactoring for the dev wishlist task but I just haven't found the time recently [20:54:49] bd808: https://gerrit.wikimedia.org/r/#/c/371584/ will get rid of MWException trying to output itself [21:07:30] tgr: nice [21:57:32] I like the two column view on https://logstash.wikimedia.org/app/kibana#/dashboard/apache2log - your own no_justification ? [21:57:38] s/your work/ [21:58:30] Prolly not