[10:34:16] <dcausse>	 we should already have all the necessary logging info to measure when second try profiles are returning results (https://phabricator.wikimedia.org/P84987). It has profile_name: plain-second-try-russian_keyboard-1 which tells us that this result comes from the plain field (no fuzziness) and using the "russian_keyboard" second try algo
[10:39:29] <dcausse>	 we just have to parse this profile_name, shouldn't be too hard and good enough if it's for an ad-hoc measure post-deployment
[10:48:17] <dcausse>	 lunch
[13:46:04] <pfischer>	 dcausse: Great! Thanks for looking into this.
[13:48:40] <pfischer>	 Regarding WDCS: I would like to get an overview of user-agents used to access WCQS, just like we have for WDQS. Where would i get that from? A hive table? Logstash?
[13:58:03] <ebernhardson>	 \o
[13:58:19] <Trey314159>	 dcausse: good news on the second try logging!
[13:58:29] <dcausse>	 o/
[14:00:11] <Trey314159>	 Any objections to cancelling the retro in favor of the staff meeting?
[14:01:23] <pfischer>	 Works for me.
[14:01:29] <dcausse>	 pfischer: should be in the hive table wcqs-external.sparql-query
[14:03:08] <dcausse>	 the UA should be in http.request_headers["user-agent"]
[14:05:53] <inflatador>	 <o/
[15:59:32] <pfischer>	 dcausse: thanks
[16:57:45] <inflatador>	 workout, back in ~40
[17:35:00] <ebernhardson>	 sigh, realized regex query has to know what version the backend is, to know if it should send 'lucene' or 'lucene_anchored' as the regex flavor to query highlighting
[17:35:32] <dcausse>	 dinner
[17:55:00] <inflatador>	 back
[18:29:44] <inflatador>	 pfischer where do you check the user-agents for wdqs or wcqs? I'm guessing there is a Jupyter notebook? Just curious as I'm wondering if we can put that info to use to help stop the WDQS meltdowns we've had lately
[18:51:56] <inflatador>	 lunch, back in ~40
[18:59:53] <pfischer>	 ebernhardson: I’ll be 2’ late
[19:00:02] <ebernhardson>	 no worries
[19:14:22] <inflatador>	 back