[00:11:09] MaxSem checking now [00:18:10] MaxSem: cooltey: exactly once per user login attempt, at least in theory. [00:18:12] however... [00:18:27] MaxSem: It looks like when do the login or requesting the csrf token [00:18:40] thanks mdholloway [00:18:57] there's a long-standing provision for auto-retrying logins if the user gets into a weird login state (i.e., the app login state somehow loses sync with mediawiki) [00:19:18] this would be evidenced by the MW API returning an anon token despite the app believing it's logged in [00:19:19] * MaxSem scratches head [00:19:55] I see a failed attempt followed by another in 2 days - are they caused by explicit user actions? [00:20:06] in this case the app clears its cookies, retrieves the user credentials, and retries logging in [00:20:36] https://github.com/wikimedia/apps-android-wikipedia/blob/a833af60708bd93d5619b9101774a182415b9778/app/src/main/java/org/wikipedia/csrf/CsrfTokenClient.java#L86-L103 [00:23:05] as far as i can see it's impossible to tell. personally, i am not a fan of the auto-retrying logins for this reason. with a two-day separation, it might very well be explicit user actions both times [00:23:36] at least MAX_RETRIES is now only 1; i believe it used to be higher [00:28:16] on the other hand, since this behavior is tied to the CSRF token data client, an implicit login could be happening anytime the app requests as CSRF token on the user's behalf, which happens rather frequently [00:29:02] *a CSRF token [00:33:37] https://phabricator.wikimedia.org/T178746#3791737 [00:33:51] what can trigger a login in this situation? [00:38:36] * mdholloway is looking... [00:47:19] ok, so [00:48:56] my info may be slightly out of date since i'm not on the android team anymore, but here's what i believe is happening, in rough outlines [00:49:01] at the beginning of a session, if the user is logged in, the app performs a couple of actions: it checks for certain notifications, and attempts to sync certain user preferences [00:49:23] it gets a CSRF token in the course of this [00:50:13] in some cases the app will attempt to re-login: [00:51:17] retryWithLogin will be called if the caller explicitly requests retrying the login [00:51:57] (this currently happens, for instance, if the user receives an error about a bad login state when attempting a wikidata description edit) [00:52:36] however, this can happen even without the caller's explicit intent in the event that the app believes it's logged in but the API returns an anon CSRF token, as i mentioned earlier [00:52:54] in this case the app will retrieve the credentials it's stored and retry the login [00:53:07] but such an automated login failed? :O [00:53:16] if these are faulty for whatever reason, then the login will fail and the user would get a notification of that [00:53:30] i do not know why this would fail, but that's what seems to be happening. [00:53:44] i can update on the ticket with this (with better references to the code) [01:01:59] thanks mdholloway! [01:02:11] MaxSem: no problem, thanks for looking into it! [01:10:46] thanks MaxSem & mdholloway [18:30:05] Hey! I'm doing T103952 from Google Code-In and I want to confirm that org.wikipedia.analytics.FindInPageFunnel is a Funnel used by Firebase, not anything else [18:30:05] T103952: Long press on find in page up / down arrows should advance to first / last match - https://phabricator.wikimedia.org/T103952 [18:38:57] Albert221: we're not using Firebase. This task shouldn't need to alter any interactions with the funnel. [18:48:26] can anyone take a look? https://streamable.com/krgfe is it fine for task above? :) [18:56:47] Albert221: that's definitely the behavior that is expected! Will have a look at your patch soon. [19:43:45] I pushed some changes to this^ [19:45:19] FlorianSW: you there? [20:53:43] do you maybe know when FlorianSW will be available? [22:25:15] JoshM: i've got a patch in the works and i'll get it deployed ASAP /cc bearND [22:33:19] tgr: hey, do you have a minute to give your blessing to a quick MCS patch for the English fundraiser? [22:33:21] https://gerrit.wikimedia.org/r/#/c/394440 [22:34:01] (re: T181743) [22:34:01] T181743: iOS app users in California seeing both US and Canada banners - https://phabricator.wikimedia.org/T181743 [22:35:36] i'm about to get thrown out of a closing coffee shop, brb in 10... [22:40:07] mdholloway|brb: LGTM. Did you test it? I don't have a test environment at hand [22:43:12] tgr: I got it. Thanks. Will deploy soon(TM). [22:51:12] mdholloway|brb: I'm prepping the deployment [22:51:58] bearND: ok! thanks. [22:56:26] SWAT delpy window coming up, though. So, the actual deployment might be delayed a bit. Will see. [22:59:02] Good thing I asked about the cache purging issue during the Services sync meeting. Will test that after the deploy. ;) [23:00:50] On the bright side, with this deploy MCS is even more ready for figure-inline. [23:01:27] https://gerrit.wikimedia.org/r/#/c/394479 [23:02:27] niedzielski: hey i noticed something odd with the lazy load demo - if i bring it up but don't scroll down (so the images beneath are presumably not fetched yet), then i disconnect from the internet, then i scroll down, the images further down are unexpectedly still loaded, which would mean they were un-lazily pre-fetched... any ideas? [23:03:05] mhurd: did you disable caching in your browser? [23:03:47] niedzielski: i cleared it each time i tried (also restarted the browser after clearing cache before re-trying) [23:04:51] mhurd: i use chromium / chrome and i can see when the images load. i believe the lazy load transform_er_ demo only allows small images to be eagerly loaded [23:05:08] mhurd: are you seeing network requests for the other images? [23:05:37] niedzielski: noticed it when i tried similar steps on trial iOS integration and i wasn't seeing expected lazy fetches when observing via a proxy as i scrolled. then i tried on the demo in case i was doing it wrong and saw same thing [23:06:24] niedzielski: oh so that demo doesn't lazy load? [23:07:02] mhurd: the demo lazy loads with the same constraints the app does. tiny images are permitted to eagerly load [23:07:10] mhurd: hold on, i'll try master [23:09:52] mhurd: i see 61 image network requests on master for my browser dimensions [23:10:27] mhurd: when i go offline and scroll, i see all the remaining images try to load and fail [23:10:54] niedzielski: oh is that LazyLoadTransform.html or LazyLoadTransformer.html ? [23:11:06] mhurd: there are some tiny images at the bottom that are eagerly loaded because their dimensions are small [23:11:16] mhurd: the latter [23:11:43] niedzielski: gotcha. trying again... [23:13:21] mhurd: both demos use LazyLoadTransform.queryLazyLoadableImages() under the covers which allows images with tiny dimensions to be loaded normally [23:16:46] mdholloway: deployed on beta cluster earlier. This time I got the update right away without doing anything special. Go figure. Deploying in prod right now. [23:17:50] bearND: that's good! [23:22:01] mdholloway: same in prod. Just worked magically this time. Only one "CA" in https://en.wikipedia.org/api/rest_v1/feed/announcements now. [23:22:30] oh wait, not yet [23:23:02] yeah, i'm still seeing both [23:23:06] better purge varnish [23:23:52] mdholloway: do you have to be on terbium for that or is any host fine? [23:24:21] bearND: i did it from terbium, not sure if possible elsewhere [23:24:48] mdholloway: gonna try scb first [23:29:46] mdholloway: scb doesn't have the command. tin and terbium do. I've ran it on both machines both no update yet. [23:30:03] both/but [23:31:44] mdholloway: ok, I think I got it now. [23:33:07] niedzielski: k retried with chrome, firefox and safari. so far seeing expected behavior on chrome and firefox, but no luck with safari... which probably explains the behavior i see on iOS... any pointers on what to zero in on for debugging? [23:33:20] bearND: yep, lgtm now! [23:33:40] mdholloway: I added some random query parameters, like in the example on the wiki page. It didn't seem to work for the feed (or RB) URLs [23:33:59] mdholloway: Once I removed them then it worked. [23:34:49] bearND: you mean like 'https://example.org/foo?x=y'? [23:34:58] mdholloway: yep [23:35:28] bearND: yeah, IIUC the cache key in varnish is the exact request URL [23:35:43] so it wouldn't surprise me if adding a query string would cause it to miss [23:36:51] mdholloway: makes sense. I just remembered using that a while ago. But I guess it's only useful on the client side for cache busting. [23:39:22] mhurd: hardcode LazyLoadTransform.isLazyLoadable() to return true. you should see zero images load in LazyLoadTransform.html [23:44:28] niedzielski: i see no images on LazyLoadTransform.html as-is. i have to tap them before they appear [23:45:22] mhurd: what does the same hardcoded change do in LazyLoadTransformer.html? [23:45:31] checking... [23:46:37] mhurd: when i go offline, everything that beyond the first screen or so fails to load [23:51:34] niedzielski: on LazyLoadTransform.html i don't see any images at all on any browser until i tap a gray box. same with the change [23:52:46] niedzielski: that's after confirming with all 3 browsers that their caches are clear [23:53:11] mhurd: what about LazyLoadTransformer.html with the change? [23:53:54] mhurd: when you go offline, you shouldn't see any images loaded beyond the first screen or so [23:59:23] niedzielski: k went offline, cleared all 3 browsers caches and confirmed they were clear by refreshing and seeing 0 images. went online and refreshed each without scrolling, seeing images initially. before scrolling at all, then went offline. then scrolled down. firefox and chrome show gray boxes all the way down. safari shows images all the way down [23:59:49] oh, this was LazyLoadTransformer.html