[00:07:41] jdlrobson: ok, let me know what you find out.. feel free to reassign it to me for another check if it turns out that it didn't go live yet [00:12:35] HaeB: not sure i believe those queries [00:12:37] manually looking through.. im seeing a lot of repeat tokens [00:13:11] ive already seen more than the 4 your query returns :) [00:14:29] also what is the table RelatedArticles_16352530_15423246 ? [00:15:10] HaeB: i think your problem is COUNT(DISTINCT event_pageId) AS pages [00:15:47] HaeB: let [00:15:54] 's check again tomorrow. I'm wrapping up for the day [00:16:46] i don't think so (i also checked 500 rows manually: [00:17:03] https://www.irccloud.com/pastebin/XIgDJdz9/ [00:17:51] ok, no rush on my side - just wanted do the check today already as promised yesterday [00:24:29] HaeB: only thing i can think is that the sampling is not per user it's per page view [00:28:10] jdlrobson: you mean that the sampling is not as described in the third bullet point at https://meta.wikimedia.org/wiki/Schema_talk:RelatedArticles#Sampling_method_and_rate ? that could be [00:29:12] correct.. it's possible bucketing happens by something else [00:29:15] this would apply for all our scheams [00:29:22] which might suggest a problem with ReadingDepthSchema [00:29:28] and page previews [00:30:18] which looks to be the case.. [00:30:45] https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/modules/ext.eventLogging.subscriber.js#L70 [00:30:48] doesnt persist.. [00:31:39] ^ HaeB [00:32:25] of course there are repeat tokens in that query result. the question is if there are different page tokens for the same session token [00:32:47] i didnt see any in the result of that query (btw the first column was named oddly, fixed here: [00:32:51] https://www.irccloud.com/pastebin/H4tCi2yU/ [00:33:26] RelatedArticles_16352530_15423246 is the old table from before the user agent switch some weeks ago [00:33:40] ^ HaeB the problem is the sampling of events we record is based on page view token and the sample for the A/B test is based on user token [00:33:42] you'll see these for all existing and active EL schemas [00:34:00] huh! [00:34:06] so there is no guarantee an Event for page view 1 would be get logged on the second page view. [00:34:06] good find ;) [00:34:18] and this will be a problem with all our schemas. Not sure how to fix it. [00:34:38] we'd need to check with krinkle who made it that way [00:34:53] again, this doesn't match the specification at https://meta.wikimedia.org/wiki/Schema_talk:RelatedArticles#Sampling_method_and_rate ("For each new session, we decide randomly whether to record events during that session (1% probability) or not (99%).") [00:35:02] so it's a bug in any case [00:35:07] interesting [00:35:24] HaeB: im saying that's wrong [00:35:31] the whole premise of the A/B is flawed [00:35:57] same goes for page previews [00:36:38] anyway ive got to go! [00:38:03] i think that's too pessimistic - for popups, we did see sessions > 1 (even at small sampling rates) https://www.mediawiki.org/wiki/File:Session_Depth_Russian.png [00:38:08] cool, let's follow up tomorrow [00:40:05] we should check everything though [00:40:20] you would see sessions > 1 [00:40:37] just maybe we're not seeing all the ones we'd expet [00:40:40] cya tomorrow [15:51:26] mdholloway: niedzielski: got a minute for a quick hangout re. retryable exceptions? [15:51:37] dbrant: sure [15:51:41] dbrant: niedzielski: sure [15:52:14] i'm en batcave [20:38:52] Extension MobileFrontend (default Minerva skin). Is there a way to display the categories at the bottom of the page? [20:38:55] niedzielski: CacheDelegate is a class you wrote and not copied from okhttp, correct? [20:39:51] mdholloway: that's right. CacheDelegate is just to expose nonpublic methods [20:40:28] niedzielski: ok cool, i'm working on updating okhttp and just wanted to double check on that. was a bit thrown off because we have it in the okhttp3 package [20:40:31] mdholloway: CacheDelegateInterceptor is derived from CacheInterceptor but there's a comment on it indicating the origin [20:40:43] there's a little bit of a chance in CacheDelegateInterceptor unfortunately [20:40:48] not too bad, though, i think [20:40:59] s/chance/change [20:41:03] mdholloway: ah, i see. unfortunately, it has to be in the okhttp package to be able to access package privates [20:41:05] (dang keyboard protector) [20:41:13] niedzielski: aha, makes sense [20:41:45] mdholloway: wrt CacheDelegateInterceptor, I believe i was pretty thorough with marking each of the few deviations with a "Change:" comment [20:41:58] mdholloway: i'll try to back you up in the patch review though [20:42:23] niedzielski: yep (thanks!), i went through line-by-line just out of paranoia but you have the deviations flagged well [20:43:36] mdholloway: cool, thanks. i think we have some similar classes for fresco that are just copies of unpublished demo implementations we use that also have to be kept up to date. i've been trying to mark these in the build.gradle file itself since they're easy to miss [20:52:04] violinwiki_: jdlrobson or bmansurov could probably answer that [20:54:44] violinwiki_: $wgMinervaShowCategoriesButton [20:54:59] although there are lots of bugs [20:55:11] and the feature has no tests [20:55:14] use at your own risk :) [21:26:10] thanks [22:25:52] Hello, I've been battling a malware problem this afternoon. Sorry for the absence.