[15:48:25] anomie: Can you verify https://gerrit.wikimedia.org/r/#/c/274966/ ? [15:59:39] * anomie looks [16:07:56] Krinkle: No, that change is not correct. [16:08:12] anomie: Would it not currently result in 'false' being embedded in the SQL query? [16:08:40] Krinkle: No, because $unwatchedPageThreshold is only used when !$canUnwatchedpages. [16:09:37] See lines 815–817, and 908–910. [16:10:12] So the variable can be alive there as 'false' but because of the rather thin co-relation ruled out earlier, that isn't the case [16:10:18] OK. But you gotta admit it's thin. [16:10:36] It never checks it directly for that branch [16:12:46] I'm not seeing it. The code could be if ( !$canUnwatchedpages ) { if ( !is_int( $unwatchedPageThreshold ) { return; } } to more closely match the test later, but we generally combine nested if statements like that into one, as is the case there. Or we could use $this->getConfig()->get( 'UnwatchedPageThreshold' ); in both places rather than storing the value in a local, but then we're making multiple calls when we could save the value in a local. [16:20:46] anomie: Yeah [16:21:42] anomie: One other thing, is it intended that bot password names and configurations are public? I noticed Special:BotPasswords now auto-completes in prefix search, but it seemed odd since it doesn't know my username. But instead of not working, it actually does work. It shows all users. And the page is visible too [16:21:46] https://www.mediawiki.org/wiki/Special:BotPasswords/K_._H_._A_._Kumarasiri [16:21:52] (not mine) [16:21:58] showing "Krinkle@K_._H_._A_._Kumarasiri" which is wrong [16:23:57] No, that auto-completion is weird and wrong. [16:23:58] * anomie will fix [16:24:37] anomie: and presumably the pages shouldn't be accessible, either? I'm curious if that means my personal names for "bot passwords" have to be globally unique. [16:24:57] Ah, I guess they are used as alternate username. not as alternate password for my user [16:25:02] Not like google app passwords then [16:25:11] Krinkle: Is there already a task for that auto-completion? [16:25:15] anomie: not yet [16:25:18] just going through post-merge [16:25:28] * anomie will file one [16:25:37] anomie: https://github.com/wikimedia/mediawiki/commit/aa8823ac4b58be611caf2595ad3c7b0ecacbc8ac [16:25:40] thx [16:25:55] Oh, WTF. Who merged that? [16:26:09] * anomie thought it was a copy-paste bug on his part [16:26:31] I'm just going to revert it then. [16:27:15] Hm.. it uses regular prefix index [16:27:31] and more over, Special:BotPasswords doesn't differentiate? https://www.mediawiki.org/wiki/Special:BotPasswords/Krinkle shows "Krinkle@Krinkle" [16:28:41] Krinkle: The $par on Special:BotPasswords is the bit after the @ for the current user. [16:29:40] There's no way to access some other user via Special:BotPasswords, since I can't think of any case in which that would be useful. [16:30:13] (except maybe for managing your bot account from your main account, but first that would need linking of accounts to be able to authz that) [16:31:29] anomie: I don't know if SpecialBotPasswords allows me to see the config of other user's bots, but it does render without error other user names in general, which is odd. E.g. https://www.mediawiki.org/wiki/Special:BotPasswords/Catrope shows "Krinkle@Catrope" - basic rights [16:33:09] Krinkle: That would be for you creating a new botpassword for your account named "Krinkle@Catrope", and has nothing to do with User:Catrope. [16:33:41] Ah, I see [16:33:43] Krinkle: It's about the same as if you visit https://www.mediawiki.org/wiki/User:Krinkle/Catrope [16:34:10] It's not showing (or trying to show) a record, but it's filled in to create a new one [16:34:39] Yes. The label at the top of the form does say "Create a new bot password" [16:34:53] That explains the odd redirect [16:35:10] Special:BotPassword POST name=Foo, redirect Special:BotPassword/Foo, then continue creation [16:35:32] anomie: Yeah, but it looked the same almost as that of an existing recor [16:35:32] d [16:35:45] I wasn't expecting /something to draft a new record [16:36:12] (also HTTP 200) [16:36:21] Its not like 'User:Krinkle/Catrope' [16:36:32] which would be 404, or on action=edit [16:36:39] anyhow [16:37:35] Well, every Special:BotPassword/Foo is like an action=edit. [16:55:29] anomie: when you were cleaning up Set-Cookie stuff did you do anything special for the forceHTTPS cookie? I just noticed on an ajax request to a wiki I haven't visited in a very long time I got both "forceHTTPS=deleted" and "forceHTTPS=true" headers on the same response. [16:56:28] probably not a big deal but it might be confusing to the crappy UAs out there in the wild [16:59:18] bd808: I did a change for forceHTTPS to make it not be deleted and re-set something like 6 times per request, but if you send one in the request and the session re-sets its cookies there's not really a way to avoid deleting and re-setting once (because we can't know what the domain and path were when the cookie is set in the request). [17:00:36] ah. I do see that the delete omits domain [17:01:01] so yeah, different keys basically [17:01:17] Yeah. What's going on there is "Delete local version of the cookie. Set CA version of the cookie." [17:01:31] *nod* [17:02:32] I'll seeing things that make me go WTF and try to figure out what's going on everywhere today. Must be paying more attention or something. [17:02:45] like edit section links on https://www.mediawiki.org/wiki/Manual:MediaWiki_architecture seem borked [17:03:22] * bd808 will purge and see what happens [17:03:52] all better after a purge. html markup was funky [17:05:01] bd808: https://phabricator.wikimedia.org/T124356 funky? [17:05:36] yup [17:08:16] bd808: The graph at the top of https://logstash.wikimedia.org/#dashboard/temp/AVNCmN87O3D718AOjAsv shows how well "unpersist unloadable sessions" did at dropping the log volume. [17:08:49] nice [22:02:58] bd808, tgr: I wonder if T125054 is that we broke some spambot with bad cookie handling? ;) [22:02:58] T125054: Sharp dip in MediaWiki.site.users metric since wmf11 roll-out - https://phabricator.wikimedia.org/T125054 [22:03:35] dream big! [22:03:54] I was wondering about that, but account creations did not change much [22:04:03] ...I think [22:04:48] .rate is comparable to pre-SessionManager, .count/.sum dropped to a fraction but I think that's just an artefact of how Graphite aggregates numbers over time [22:05:40] should probably just graph account autocreation numbers from the logging table [22:05:41] .sum is the "real" metric isn't it? [22:06:53] well, compare https://graphite.wikimedia.org/render/?width=586&height=308&from=-7days&target=timeShift(MediaWiki.authmanager.accountcreation.web.success.rate%2C%2242d%22)&target=MediaWiki.authmanager.accountcreation.web.success.rate with https://graphite.wikimedia.org/render/?width=586&height=308&from=-7days&target=timeShift(MediaWiki.authmanager.accountcreation.web.success.sum%2C%2242d%22)&target=MediaWiki.authmanager.accountcreation.web.success.sum [22:07:07] these are web users, not bots [22:08:01] either we completely broke registrations, which I'm sure would have been noticed, or .sum is not invariant over time [22:09:40] the red and green line actually have the same shape there but there is about 50x difference [22:10:36] as I understand Graphite will compress old logs in such a way as to preserve the average [22:13:05] so you have 100 events with a value of 10 and a resolution of 10 seconds (ie. statsd collected 10 events in the 10 sec interval that it uses as a buffer before sending to graphite) [22:14:00] and then those events become old and graphite compresses them into a single event with a resolution of 1000 seconds, and the new value will be 10 (average of old values) [22:15:09] although that would suggest that .sum is smaller for older dates and the opposite is happening [22:15:36] so not sure what's going on but empirically .rate is what's behaving sane [22:17:42] compare https://graphite.wikimedia.org/render/?width=586&height=308&from=-10days&target=MediaWiki.authmanager.accountcreation.web.success.sum with https://graphite.wikimedia.org/render/?width=586&height=308&from=-100days&target=MediaWiki.authmanager.accountcreation.web.success.sum [22:18:00] the graphs remain level but the second is 10x higher [22:18:07] with rate they match up [22:41:09] robla: can you flowify https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2016-17_Goals/New_MediaWiki-focused_team/Platform_proposal as well, for consistency? [22:41:43] * robla doesn't know the answer to that [22:41:57] is that something that I'm the only one with permission to do? [22:43:06] tgr: I have no problem in principle with doing that; I just don't have the time/energy to figure out how to do it. [22:44:15] Special:EnableFlow [22:47:11] robla: sorry, I thought you did it for the main proposal page [22:47:18] I'll look into it then [22:47:59] (it was James apparently) [22:48:57] legoktm: does that take the main page or the talk page as the parameter? [22:49:09] talk page I think [22:50:19] Yes, the talk page [22:50:35] This is because you may also want to Flowify pages like [[Wikipedia:Village pump]] [22:50:50] Which is a discussion page but is not in a talk namespace