[00:32:40] legoktm: only 2 left! https://github.com/wikimedia/composer-merge-plugin/pulls [02:01:01] bd808: will monolog lazy-evaluate arguments? [02:02:46] e.g. $logger->debug('{foo}', array('foo'=>$objectWithExpensiveToString)) [02:03:15] would this keep the expensive operator from happening when no handler cares about debug level? [02:03:32] or is there a nicer way to handle such issues? [04:08:57] tgr: yeah, monolog won't toString() foo until after at least one handler says that it will do something with the record [04:09:15] that's one of the good use cases for the context [04:18:00] the working part of the logger is https://github.com/Seldaek/monolog/blob/master/src/Monolog/Logger.php#L274-L325 [04:19:42] stringification happens way down in the formatters that are attached to handlers -- https://github.com/Seldaek/monolog/blob/master/src/Monolog/Formatter/NormalizerFormatter.php#L97-L99 [04:21:37] although actually in our case it would happen in the processors when PsrLogMessageProcessor gets to run -- https://github.com/Seldaek/monolog/blob/master/src/Monolog/Processor/PsrLogMessageProcessor.php#L27-L47 [06:45:25] bd808: so if you have a blackhole logger, that would work, but if you have a normal logger with processors and and a minimum loglevel, that won't? [06:46:00] I wonder if this should be a monolog feature request [06:47:33] $logger->debug('{foo}', array('foo' => new \Monolog\LazyArgument(function() { return superExpensiveCalculation(); }))); [06:47:40] or something like that [06:48:51] it kind of breaks the loose coupling between logger and application though [16:00:15] tgr|away: the processors aren't fired until a handler has said it will handle the record so it would still be fine with a level trigger (eg if the handler is >=info and the record is debug then addRecord() will exit before applying the processors) [19:39:25] Hmm. Does anyone else see FOUC on the api help page? [19:40:06] Is it actually a bug? [19:40:30] Do we care? [19:41:38] Reedy: I don't see a FOUC, but we do care... [19:41:45] Imma file a bug [19:41:51] I see it effectively every time I load it [19:42:15] well, stuff moves around when it finishes loading [20:28:34] Do we need to file a request to get a User- project thing created? [20:36:19] bd808: ^ [20:41:39] Reedy: yeah. A task in the project-creators project on phab [20:42:11] I have project creator rights... :P [20:42:29] Still worth doing the book keeping :) [22:13:44] bd808: there are some exceptions in exception.log coming from monolog and related to character encoding and json [22:14:36] non utf-8 data in the logs then? [22:15:31] yeah [22:17:21] I think that was a change in the new monolog version we updated to... let me check the changes there [22:17:41] My recollection is that they used to silence that and ignore and now they whine [22:19:15] bd808: where does the URL get added to the log message as context data? [22:19:59] it's added by the WebProcessor in the log config [22:20:50] Here's the change that makes that exception.log entry -- https://github.com/Seldaek/monolog/commit/0c8a92af4759ee6d53c4c8a4d7a923d22d0c3da2 [22:21:02] it used to be silent about that hapening [22:22:10] So I guess now the question is what is calling toJson() with ignoreErrors = false [22:22:14] it looks like a bona fide monolog bug, because mediawiki is not involved -- the uri field comes from WebProcessor, as you note, and it just uses $_SERVER [22:22:37] bd808: it doesn't check $ignoreErrors any more? [22:22:57] oh never mind, yes it does [22:23:22] bd808: monolog/src/Monolog/Formatter/LogstashFormatter.php:84: return $this->toJson($message) . "\n"; [22:23:29] yep [22:24:17] I wonder if they did that on purpose? [22:24:47] i don't think so; they probably didn't test that combination [22:24:50] GelfFormatter also leaves off the suporession flag [22:26:46] the one example I'm looking at in the logs has the non-utf8 char in the refererrer data [22:27:01] we should probably call htmlentities() on that and the request uri [22:27:30] yeah. Maybe we should just drop using that processor and make our own? [22:28:14] hmm -- why? i see nothing here that is unique to us [22:28:54] we can try to upstream for sure [22:32:26] oh! It looks like we can fix it via config only [22:32:46] the constructor for the processor can take an array of data