[19:48:20] <matanya>	 niedzielski: hi
[19:48:37] <niedzielski>	 matanya: o/
[19:49:16] <matanya>	 niedzielski: i am getting this with every edit on lastest alpha :https://phabricator.wikimedia.org/T154414
[19:51:08] <niedzielski>	 matanya: hm, this might be a caching issue that i'm looking into. would you mind clear your app cache under the system app settings for wikipedia alpha?
[19:51:37] <matanya>	 i did that, did login/out, rebooted
[19:57:50] <niedzielski>	 matanya: :/ well i'm glad it's not a caching issue. i'm trying to repro over here but i have a meeting momentarily. i'll follow up on the old ticket
[19:58:02] <matanya>	 thanks
[20:42:37] <mdholloway>	 niedzielski: believe it or not i just reproduced it
[20:43:37] <niedzielski>	 mdholloway: anything telling in the log? is this cache related?
[20:45:00] <mdholloway>	 niedzielski: nothing in the log that i can see.  i don't think the log reflects when a response comes from cache (i.e., it's just reported as a normal 200), right?
[20:46:00] <mdholloway>	 doing a CSRF request with curl, there's no no-cache header, (i got Cache-control: private, must-revalidate, max-age=0) which makes me suspect this is cache related too
[20:46:14] <mdholloway>	 but let me make sure it's the same when logged in
[20:46:46] <niedzielski>	 that's right, but which request is failing? is this a GET?
[20:48:54] <mdholloway>	 https://www.irccloud.com/pastebin/iNHZEV3J/
[20:50:00] <mdholloway>	 niedzielski: otoh, i was editing earlier today without issue, even after we'd discovered the caching problems
[20:52:17] <mdholloway>	 the csrf token requests themselves are showing up as 200s
[20:52:20] <mdholloway>	 debugger time!
[20:53:23] <niedzielski>	 mdholloway: AFAIK, POST requests should not be cached regardless of cache-control settings
[20:54:00] <mdholloway>	 the CSRF token request is a GET
[20:54:15] <niedzielski>	 mdholloway: maybe it an issue with the token request itself, CsrfTokenClient
[20:54:22] <mdholloway>	 yeah, could be
[20:55:10] <niedzielski>	 mdholloway: if you comment out the two interceptors in OkHttpConnectionFactory, does the issue still occur?
[20:57:44] <mdholloway>	 niedzielski: trying that now.  but debugging sectioneditclient, the same token was definitely coming back every time
[20:58:06] <mdholloway>	 niedzielski: commenting out the new interceptors solves it
[20:58:35] <niedzielski>	 mdholloway: thanks, then caching. i'm working on a fix over here
[20:59:43] <mdholloway>	 another funny thing is, description editing also makes the CSRF call each time, and was succeeding...
[21:00:11] <mdholloway>	 but yes, caching needs fixing at any rate.  
[21:00:57] <niedzielski>	 i think part of the caching issue is in CacheControl's builder constructor which unconditionally drops mustRevalidate
[21:25:07] <mdholloway>	 niedzielski: not to distract, but mind giving this a +2? i'd like to see if it gets the periodic test job building consistently again https://gerrit.wikimedia.org/r/#/c/336488/
[21:25:32] <mdholloway>	 i can try to get those to green again while you're working on the caching stuff
[21:25:43] <niedzielski>	 sorry, i haven't responded to your email
[21:25:57] <mdholloway>	 no worries, other stuff more important!
[21:26:16] <mdholloway>	 i can work on the screenshot test failures at any rate
[21:26:34] <niedzielski>	 i'm happy to +2 this but i'll be a little surprised if it has much of an impact since the tests fail before gradle starts: https://integration.wikimedia.org/ci/job/apps-android-wikipedia-periodic-test/1298/console
[21:26:36] <niedzielski>	 I suspect it's due to lack of hardware GPU support causing extraordinarily slow emulator performance
[21:26:56] <niedzielski>	 i believe the screenshot test failures should all be fixed as of yesterday but i could be mistaken
[21:27:45] <mdholloway>	 but fwiw as of today i have to go up to -Xmx4096M even locally to get them to run all the way through without timeouts :[
[21:28:30] <niedzielski>	 hm, that's very interesting
[21:28:32] <niedzielski>	 well, i'll +2 and hope for the best
[21:28:38] <mdholloway>	 oh, i saw a couple of failures locally earlier but let me run through again and double-check
[21:29:21] * niedzielski sent a long message: niedzielski_2017-02-07_21:29:20.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/FWunCSOBQXBhkYfgiuvZELWo
[21:29:39] <mdholloway>	 niedzielski: cool, thx - can always be reverted if it's ineffective or counterproductive...
[21:29:41] <niedzielski>	 er, that's a bit mangled: https://github.com/niedzielski/dotfiles/blob/master/home/stephen/.gradle/gradle.properties
[21:31:13] <mdholloway>	 niedzielski: mine was the same.  today i was consistently running into timeout failures during the PageLoadTests before bumping to -Xmx4096M
[21:32:05] <niedzielski>	 mdholloway: hm, well the PageLoadTests are actually @LargeTest so those don't run in ci
[21:32:31] <mdholloway>	 niedzielski: hmm, true.
[21:35:29] <niedzielski>	 mdholloway: you should think about getting a jenkins account if you like some of the ci stuff
[21:35:35] <niedzielski>	 then you can just make these changes on the fly in a test job
[21:36:25] <mdholloway>	 niedzielski: ah!  i did not know that was a possibility.  that would be awesome.  i was looking at some documentation about on-demand builds but didn't see it in our UI
[21:37:23] * mdholloway tries logging in and immediately succeeds
[21:37:27] <mdholloway>	 palm -> forehead
[21:37:58] <niedzielski>	 mdholloway: i think this was my jenkins ticket if you do hit permission issues: T103192
[21:37:59] <stashbot>	 T103192: Request Jenkins shell access for account "sniedzielski" - https://phabricator.wikimedia.org/T103192
[21:39:04] <niedzielski>	 mdholloway: anyway, i think if you just clone (and temporarily disable) the periodic job, you can make all your changes in the little shell input
[21:39:44] <niedzielski>	 (the reason you have to disable the current job is that the server is too slow to run two builds simultaneously)
[21:40:59] <niedzielski>	 it'll be hard to screw up anything if you stick to the web ui
[23:24:21] <mobrovac>	 bearND: do we have a task for https://gerrit.wikimedia.org/r/#/c/336259/ ?
[23:24:22] <mobrovac>	 we need to implement that in RB as well to take effect
[23:48:20] <mobrovac>	 bearND: do we have a task for https://gerrit.wikimedia.org/r/#/c/336259/ ? (not sure if you got my msg earlier, got conn problems)
[23:52:23] <bearND>	 mobrovac: no, we don't have a task for it. I don't think we need to expose it in RESTBase at this time. I only need it for testing MCS itself at this time.
[23:54:28] <mobrovac>	 kk bearND, thnx for the info