[04:23:37] bd808: I was thinking of how log errors/warnings could be exposed when calling some service in a maintenance script [04:24:25] it's easy enough to write a Logger wrapper which echoes to the terminal, but where would it be injected? [04:25:14] making loggers injectable everywhere would mean the injecting code would have to know what channel to use, which seems awkward [04:25:37] yeah. that's the funky part of both PSR3 and our channel system [04:26:07] so either LoggerFactory injection or replacing the SPI in maintenance scripts? [04:26:09] what you really want to do is override the config for the logger output [04:26:15] neither is very likeable [04:26:55] or we do oris rfc to completely rethink maintenance scripts [04:27:31] that would be cool but I don't see the relation [04:28:06] it would give a better place to control things like logging I think, but I may be reaching [04:28:26] what is it that you really want? to send some log channels to stderr? [04:28:57] it seems unlikely that you'd want everything to go there [04:29:47] with monolog it wouldn't be too hard to add a configuration point where a script could say what channels to send to stderr [04:30:07] we really should make monolog the default logger and kill off LegacyLogger [04:31:08] also E_TOO_MANY_THINGS to add another :) [04:31:20] logs above info to stderr would be a good start IMO [04:31:41] ideally, prefix every line with something [04:32:33] that would all be doable with monolog [04:32:49] yes, a monolog handler would be one approach, although having the sysop and the framework share the responsibility for configuring the logger seems fragile [04:34:07] heh. isn;t that most of what legacylogger does? [04:35:25] so... how else could we do it... [04:36:05] wrap the SPI, wrap the logger factory, wrap the logger [04:36:20] an SPI that wraps the default SPI and sends log events to the default and to a special console SPI wouldn't be too ugly [04:37:33] so the console entry point could grab $wgMWLoggerDefaultSpi and make the swap. [04:39:02] cool, I'll try that [04:39:31] is there any need to mess with wgMWLoggerDefaultSpi? [04:40:13] as opposed to LoggerFactory::registerProvider( new ConsoleSPIWrapper( LoggerFactory::getProvider() ) ) ? [04:40:49] yeah, that would be better than poking the global [04:41:29] ou'd have to reset LoggerFactory anyway [16:23:22] Reedy hi, im wondering could you review https://gerrit.wikimedia.org/r/#/c/309843/ please? [16:24:24] paladox: The better fix would be to make sure it was defined up at the top of the function [16:24:37] Though, what you're fixing would look like it can't happen [16:24:44] Yeh [16:24:48] me too, confusing [16:24:53] but seems to break somewhere [16:25:18] I'd move the definition from the top out of the conditional [16:25:21] Rather than doing what you did [16:25:30] Oh [16:26:13] Reedy so move it up above if ( $isPreview ) { ? [16:26:38] Or move it on line 58 [16:26:46] above line 57 [16:26:53] ? [16:27:55] Thanks for comments [16:27:58] will do it now [16:27:58] :) [16:30:02] Reedy done [16:59:18] Quick pointer, anyone, to a standard way of deferring a non-time-sensitive operation until db replica lag has caught up? [16:59:47] AndyRussG: a job with waitForSlaves() [17:00:26] bd808: ah nice! [17:00:52] a differed update might work too [17:04:19] bd808: wfWaitForSlaves() ? https://doc.wikimedia.org/mediawiki-core/master/php/GlobalFunctions_8php.html#a47091dcda629e274d4b9389063ed1258 [17:05:18] A deferred update + waitforslaves seems best. [17:05:35] So it won't block the user's request and will wait for the slaves to catch up. [17:05:47] ostriches: so call waitforslaves from within a deferred update? [17:05:51] Yep [17:06:06] ostriches: bd808: cool! thx much!! :) [17:06:13] yw [17:07:10] AndyRussG: yeah although I think the new hotness is LBFactory::waitForReplication [17:39:56] bd808: hm! [17:40:53] bd808: another thought (might also be a workaround for the same issue I'm facing) is there a way to globally protect a namespace? [17:41:08] ostriches: ^ [17:42:40] AndyRussG: Yes. https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection [17:48:26] ostriches: ah nice! [17:49:11] Hmmm also is it a bug in core if, when creating a page and then protecting it right away in the same request, you get an error because DB lag? [17:50:33] Never heard of it, but I could see it being true [17:56:03] those should both be write requests which go to the master, so the replica lag issue would be systemic rather than specific to that operation I'd think. But you can get a replag failure at pretty much and write operation [17:59:12] anomie: hi there [17:59:19] matanya: ? [17:59:24] is this warning a concern: [17:59:25] Session "[50]CentralAuthSessionProvider<-:2597659:Chelbig1>ln3m6j0hkmn7o5ibq1ndvsmekmq2kujr": Metadata merge failed: exception 'MediaWiki\Session\MetadataMergeException' with message 'Key "CentralAuthSource" changed' in /srv/mediawiki/php-1.28.0-wmf.20/includes/session/SessionProvider.php:205 Stack trace: #0 /srv/mediawiki/php-1.28.0-wmf.20/includes/session/SessionManager.php(636): MediaWiki\Session\SessionProvider->mergeMetadata() #1 /srv/ [17:59:25] mediawiki/php-1.28.0-wmf.20/includes/session/SessionManager.php(505): MediaWiki\Session\SessionManager->loadSessionInfoFromStore() #2 /srv/mediawiki/php-1.28.0-wmf.20/includes/session/SessionManager.php(189): MediaWiki\Session\SessionManager->getSessionInfoForRequest() #3 /srv/mediawiki/php-1.28.0-wmf.20/includes/WebRequest.php(734): MediaWiki\Session\SessionManager->getSessionForRequest() #4 /srv/mediawiki/php-1.28.0-wmf.20/includes/session/ [17:59:25] SessionManager.php(128): WebRequest->getSession() #5 /srv/mediawiki/php-1.28.0-wmf.20/includes/Setup.php(759): MediaWiki\Session\SessionManager::getGlobalSession() #6 /srv/mediawiki/php-1.28.0-wmf.20/includes/WebStart.php(137): include() #7 /srv/mediawiki/php-1.28.0-wmf.20/api.php(38): include() #8 /srv/mediawiki/w/api.php(3): include() #9 {main} [17:59:41] dammit, large paste [18:01:00] matanya: Not particularly. It happens when the code to prevent T124409 triggers. [18:01:00] T124409: Logging out immediately logs you back in - https://phabricator.wikimedia.org/T124409 [18:01:18] ok, thanks anomie [18:03:53] It's something like "user logs out → source gets set to Local → subsequent request attempts to still use the central session → 'Local' !== 'CentralAuth' prevents that from happening" [18:03:56] IIRC [18:10:19] addshore: Any thoughts on that ApiQueryWatchlist thing I asked you about a few weeks ago? You can see now what I did for ApiQueryRecentChanges in , prior to your watchlist thing I'd have done the same for ApiQueryWatchlist. But now I'm not sure where to be able to hook into it. [18:10:31] ostriches: bd808: yeah it's a new thing that's happening. Happens because in the code to protect a page, it creates a new revision, which validates existing content, which is gotten first from the cache, and on cache miss, from the replica. I guess it doesn't hurt to file a task just in case... FYI here's the task about the original issue (in CentralNotice): https://phabricator.wikimedia.org/T146880 [18:12:02] I guess it's a little like a user not seeing his/her edit right away because lag, but from the point of view of an API consumer rather than a real user [18:12:46] I belive this may be causing mediawiki problems [18:12:51] mediawiki.org [18:12:56] causing pages to not load [18:13:04] paladox: ? [18:13:20] See #wikimedia-operations [18:13:34] bblack said something about centralauth, and that error looks like centralauth [18:15:07] anomie: is https://gerrit.wikimedia.org/r/#/c/290446/ safe to go? [18:16:01] paladox: ah hmmm checking it out (just fyi the issue I'm working on is CentralNotice, not CentralAuth) [18:16:32] Oh, i was meaning CentralAuth from the error posted above ^^ [18:16:59] paladox: ah sorry :) [18:17:06] :) [18:17:16] Oops. Name clash :-/ [18:17:19] http://opensource.googleblog.com/2016/10/introducing-cartographer.html [18:18:05] legoktm: Should be. I suppose technically it could wait until the utfnormal patch you just merged is actually added to the mediawiki/vendor repo. [18:21:06] anomie: I'll have time to do the utfnormal release in about an hour...should it be a new major version? or just bump minor? [18:21:35] anomie: I havn't looked yet, but I'll look right now! [18:21:57] regarding https://phabricator.wikimedia.org/T122689#1939440 right? [18:23:56] legoktm: I have no idea. [18:24:02] addshore: Yes. [18:24:20] anomie: I mean, upgrading unicode shouldn't be a breaking change right...? [18:25:05] * legoktm bbl [18:25:41] legoktm: In theory, I believe the normalization is forward-compatible since it only affects characters that were newly added in the new version of Unicode, or something like that. [18:28:11] AaronSchulz, https://gist.github.com/MaxSem/c15c4a1715d80f71f4b8ebf47c5221a7 [18:29:03] AaronSchulz: >> https://gerrit.wikimedia.org/r/#/c/314241/ [18:40:41] anomie: it looks like this ores stuff should be a method added in the WatchedItemQueryService class? [18:45:40] addshore: Can't add a method from an extension, though, I think. If I were doing it, I'd probably add hooks along the lines of what I added to the API in : one to modify the query (for wlshow), one to bulk-query scores for all the rows, and one to take the bulk-query data and add it to the $recentChangeInfo for each row. Or some other mechanism that has the same effect of registering three callbacks at [18:45:40] those three points in the execution. [18:45:50] MaxSem: I amended https://gerrit.wikimedia.org/r/#/c/314241/ [18:46:27] bah anomie I totally missed that https://gerrit.wikimedia.org/r/#/c/313831/4 was in an extension.. [18:47:05] addshore: And then we'd still need some way for $watchedItemQuery->getWatchedItemsWithRecentChangeInfo() to indicate continuation. [18:48:01] addshore: Or we could potentially move the bulk-query bit into ApiQueryWatchlist, with the disadvantage that any future thing that wants to do the same thing would have to duplicate code. [18:49:56] addshore: And in any case it'd be nice to have a signal so the extension can know whether any of this is actually necessary. [18:53:16] I'd be interested to see the hook idea, I think that would scale nicely for other extensions that wanted to do things too [18:55:12] you can almost think of the WatchedItemQuery stuff as already doing that, but in a less flexible way, it's altering the regular query, and then returnning extra stuff.. [18:56:26] I dont like the idea of moving the bulk stuff into ApiQueryWatchlist much :/ [18:59:09] I'll try to put some code together for that then. I might wind up making a "WatchlistQueryServiceExtension" interface with one hook to inject instances, instead of a half-dozen hooks to mess with each piece of its operation. [19:00:14] bd808: does https://gerrit.wikimedia.org/r/#/c/312970/ look good to you now? [19:10:45] SMalyshev: awesome. I'll test it out [19:12:54] bd808: thanks! I'm not 100% sure I figured out how hiera handles merging different hierarchical configs and whether I should've used something like hiera_hash but decided to keep it simple [19:15:20] *nod* we may need to make it fancier at some point but this feels like a good start. [20:00:28] MaxSem: maybe it's another extension? [20:01:26] AaronSchulz, that was isolated to one parser test file that wasn't using any cross-wiki features [20:01:52] I just removed everything that required the commons role [20:10:37] legoktm: https://gerrit.wikimedia.org/r/#/c/314340/2 [20:10:52] (and greg-g ) [20:14:15] AaronSchulz: I'm at school today, won't have time to review for 5-6 hours probably [20:29:44] AaronSchulz: who else can review. do you think? Since this is blocking the train... (cc thcipriani ) [20:40:02] AarronSchulz hi, im wondering if you could take a look at https://phabricator.wikimedia.org/T147511 please? [20:40:17] Woops wrong username AaronSchulz ^^ [20:47:26] AaronSchulz, greg-g : {{Done}} [20:50:34] anomie hi, im wondering what do we use getDBLoadBalancerFactory in REL1_27, what i mean is getDBLoadBalancerFactory only exist on mw 1.28 alpha not 1.27, what should we use instead of getDBLoadBalancerFactory on REL1_27? [20:50:39] tgr ^^? [20:50:50] https://phabricator.wikimedia.org/T147511 [20:52:15] bd808: thanks! [20:52:38] thcipriani: ^ aaron's patch is merged, but now it's almost 2pm [20:52:43] paladox: probably easiest to backport the core patch which added that service [20:52:50] we're good until 4 though [20:53:02] yeah, I think there's still time [20:53:10] cool [20:53:10] rolling to group1 only takes a minute [20:53:15] yup [20:54:35] backported, just waiting on zuul [20:55:05] tgr ok [20:55:09] i will have a look [20:55:13] to see how it was added [20:55:14] thanks [20:55:18] I was thinking that too [20:58:21] tgr https://gerrit.wikimedia.org/r/#/c/286314/ seems to be a big patch [21:04:27] AaronSchulz: getting ready to sync you change, trying to think of the simplest way to do that. Is it fine to sync maintenance/lag.php and then just sync-dir includes/libs/rdbms? [21:06:20] thcipriani: seems like that should work [21:06:32] thanks :) [21:15:23] tgr https://gerrit.wikimedia.org/r/314420 :) [21:15:26] would that work? [21:25:37] tgr would this wfGetLBFactory work for now? [21:28:32] I belive we could use this wfGetLBFactory on 1.27.1 [21:28:39] Woops wrong place [22:14:35] AaronSchulz could you merge https://gerrit.wikimedia.org/r/#/c/314425/ please?