[02:13:29] MatmaRex: done [02:13:42] Jenkins was super slow today [02:13:47] thanks [16:56:02] anomie: just ran into this: https://phabricator.wikimedia.org/T135525 [16:56:53] could this be related to the force-use flag somehow? [17:00:38] on second thought, https://gerrit.wikimedia.org/r/#/c/289166 seems more likely [17:15:18] tgr: https://gerrit.wikimedia.org/r/#/c/289166 seems very suspicious to me. It seems like every time something is changed to use DeferredUpdates like that we run into strange race conditions. [17:16:52] anomie: yeah, just trying to figure how to live-hack beta to test it without that patch [17:17:15] (well, pleading for bd.808 to figure it out for me) [17:18:25] tgr: force-use is very unlikely, since CentralAuth only sets the flag in CentralAuthTokenSessionProvider, which isn't being used there. [17:18:50] ah, I totally missed that [17:19:55] tgr: I don't suppose we know when exactly this started? [17:20:45] no [17:23:17] tgr: I don't suppose you can reproduce in mediawiki-vagrant? Mine is still broken (T132449). [17:23:17] T132449: Mediawiki-vagrant setup.sh fails - https://phabricator.wikimedia.org/T132449 [17:23:47] let me try, although if it's a DB race condition... [17:30:31] tgr: Looking at the database for a logout attempt, I see my test user's gu_auth_token did not get changed like it should have. [17:33:33] tgr: I also see the call to http://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralAutoLogin/deleteCookies?type=icon is complaining "Cannot delete cookies while still logged in" (I'm glad I added that X-CentralAuth-Status header) [17:36:34] bd808, ori: I don't X-Wikimedia-Debug works in Beta Labs? [17:37:04] I don't think it does anything special there, no [17:37:41] Prod uses some varnish magic and a small routing app I think to pin requests to the server from the header [17:37:50] anomie: ooh, I can actually repro in vagrant [17:38:06] tgr: Awesome! Then you can bisect it. [17:38:15] (just had to disable the zillion "block account creation" filters I had for testing) [17:40:24] anomie: yup, goes away as soon as I rebase 7935ca7fef62 out [17:40:55] ... Random guess at what's happening: In rECAU7935ca7fef, by the time DeferredUpdates gets called the User object has been reset to an anon so CentralAuthUser::getMasterInstance() doesn't do the right thing. Before the patch, we got the CentralAuthUser before that. So fixing it might be as simple as storing $username = $user->getName() outside the DeferredUpdates and using CentralAuthUser::getMasterInstanceByName() inside the callback instead. [17:42:37] tgr: ^ If you want to test that [17:46:51] anomie: works [17:47:40] tgr: So, do you want to submit the patch and I'll merge, or should I write it and you merge, or should we just tell the people who broke it how to fix it? [17:47:57] I'll submit [17:51:51] anomie: https://gerrit.wikimedia.org/r/289248 [17:52:29] (and I'll have another UBN patch for you in a few minutes, that one was broken by me) [17:52:50] +2ed [18:00:32] anomie: https://gerrit.wikimedia.org/r/289250 https://gerrit.wikimedia.org/r/289251 [18:01:14] and also affects ContactPageFundraiser but I presume that does not use the usual deploy schedule [18:03:21] tgr: Comment on https://gerrit.wikimedia.org/r/#/c/289250/ [18:32:09] anomie: thanks, fixed [18:33:01] btw, tomorrow is the brainstorming meeting for Q1 goals [18:33:52] Goal: Avoid goal-setting processes. [18:34:16] I made a copy of our previous etherpad at https://etherpad.wikimedia.org/p/reading-infra-2016-17-q1, if you have new stuff please add it [18:34:38] also we should probably add the most important ones to https://www.mediawiki.org/wiki/Reading/Quarterly_planning/FY2016-2017/Q1 otherwise someone else will pick for us [18:35:17] my pick is OAuth I think [18:35:36] apart from the various AuthManager followups which I suppose we will have anyway [18:44:14] tgr: Re the one on there about OAuth2, there's also a reason we chose OAuth1. IIRC, it's not even guaranteed than different OAuth2 implementations can interoperate. [18:44:40] Oh, look: https://en.wikipedia.org/wiki/OAuth#Non-interoperability [18:44:58] um, support em all? :P [19:03:24] anomie: IIRC csteipp wanted us to support OAuth2 eventually, but it's not a huge priority [19:03:40] I'm more interested in usability improvements [19:04:18] (csteipp: talking about possible Q1 goals for reading infrastructure) [19:04:48] Eventually, I think it would be good to support one standard OAuth2 flow, but right now openid connect is trying to write a hardened spec. [19:04:58] So I think it would be beneficial to wait for that [19:05:12] See how that affects the specifics of the two flows that they support [19:06:16] I think the goal of moving to OAuth2 is to use OpenID Connect instead of /identify, so it's more standard. And make our stuff Just Work with code that does OAuth2/OIDC with Google. [19:06:36] s/is/should be/ [19:15:55] bd808: any tips who could review https://gerrit.wikimedia.org/r/#/c/289263/ ? [19:16:03] it doesn't even have en extension page [19:17:02] that extension looks like abandonware :/ [19:20:46] tgr: "Copyright © 2006 Daniel Kinzler" -- but it looks to not really have been maintained at all since brion split it out of core in 2009 [19:21:46] I heard Fundraising likes to use old code :) [19:21:55] but I'll just ignore it then [19:23:20] Roan renamed it 6 years ago. We should make him review the chagnes ;) [19:26:33] tgr: blindly +2'd. We can fix it if it turns out that a) anyone anywhere uses it and b) that the change somehow isn't correct [19:29:42] thanks [21:39:42] tgr, dr0ptp4kt: https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updating_tips, please fix anything I screwed up. I'll write and send the email tomorrow. [21:53:39] anomie: noted, thanks (i did a quick full read and it read clearly, although tgr has the knowledge on the internals) [22:52:43] Is there an (easy?) way to export extraData in an api response that failed whilst retaining automatic errorCode $messageMap mapping? I'd like to export a parsed interface message from ApiRollback for https://gerrit.wikimedia.org/r/#/c/242050/ since there are so many combinations of messages and parameters, exporting it all and reverse engineering / syncing [22:52:43] client-side doesn't make sense. [22:53:12] It seems if I use dieUsageMsg() there is no extra data option. and if I use dieUsage(), I need to check and fallback 'info' manually from ApiBase messageMap [23:20:44] Worked around for now - https://gerrit.wikimedia.org/r/#/c/242050/21/includes/api/ApiRollback.php