[10:52:32] <dcausse>	 lunch
[14:25:48] <ebernhardson>	 \o
[14:40:45] <inflatador>	 \moti wave2
[14:40:49] <inflatador>	 .o/
[14:41:08] <inflatador>	 slashes are out of alignment today ;P
[14:41:13] <ebernhardson>	 :)
[14:48:40] <ebernhardson>	 dcausse: curious your thoughts, i poked through the dispatcher/routing/etc. bits yesterday, what do you think of adding a CONTEXT_SEMANTIC (alongside ft/comp suggest/prefix).  query route selects it based on CirrusDebugOptions, etc.
[14:51:03] <dcausse>	 ebernhardson: sounds good to me, something I forgot to mention is that the route must only accept a strict ns=0
[14:51:32] <dcausse>	 for instance eswiki has multiple default search namespace but only ns_main will have the knn index
[14:51:51] <dcausse>	 something we might have to tell the android app to explicitly set I think
[14:52:01] <ebernhardson>	 dcausse: ohh, i hadn't thought of that, indeed was expecting ~= default searchable namespaces.  Will do
[14:52:54] <dcausse>	 and also we seem to exposing all query builders by default, perhaps we should keep the knn one "hidden" from the api help but not sure there's anything to prevent builder profiles to be exposed
[14:53:30] <ebernhardson>	 hmm, can probably add an extra profile param to indicate un-documented, default to false if not set.
[14:53:36] <dcausse>	 sure
[14:54:31] <ebernhardson>	 might be weird in some cases, will have to see. Maybe api will have to get a special function it calls to ask for documented profiles
[14:57:13] <dcausse>	 yes not sure how to make this client friendly yet...
[14:58:22] <ebernhardson>	 i suppose i was also waffling on CONTEXT_SEMANTIC because the other contexts are covering different entry points, this is varying the fulltext entry point, but it's probably ok
[14:58:39] <ebernhardson>	 well, i guess comp suggest / prefix is same
[14:58:55] <dcausse>	 wikidata is using contexts too
[14:59:04] <dcausse>	 from Special:Search
[14:59:10] <ebernhardson>	 ahh, ok, so not that out of place
[15:02:43] <dcausse>	 very possible that in the end there might be a need for a dedicated api endpoint...
[15:02:57] <dcausse>	 or use srwhat like Dmitry suggested
[15:03:07] <dcausse>	 but that needs more plumbing I think
[15:03:43] <ebernhardson>	 i've never been a fan of srwhat :P  But yea that's a possiblity too
[15:14:43] <dcausse>	 heading out, have a nice week end
[16:37:31] <inflatador>	 <o/
[17:33:47] <ebernhardson>	 err...wow.  `find extensions/CirrusSearch/tests | wc -l` is 2.6k files
[17:34:13] <ebernhardson>	 to be fair, that includes 2085 fixtures, but still :P
[17:34:40] <ebernhardson>	 the problem is it's just so much work to dig through and figure out which 1000 of those are basically duplicate functionality of other fixtures
[17:35:26] * ebernhardson idly wonders if some sort of code coverage thing that runs each one separately and then analyzes which things hit all the same code is viable...but that sounds like the exact opposite of what i need to do :P
[18:03:57] <ryankemper>	 inflatador: patch to provide trueg wdqs root access here: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1227862
[19:05:16] <ebernhardson>	 hmm, realizing i don't know where the query vector will come from exactly.  Liftwing, but should we use ORES/LiftWing? or some thin abstraction of our own?
[19:06:53] <ebernhardson>	 or do we use neural query instead of knn and lean on some sort of opensearch->liftwing integration/
[19:24:54] * ebernhardson probably has to hack in some way for my local dev env to query relforge...
[19:53:32] <inflatador>	 ryankemper 👀
[19:55:41] <inflatador>	 gerrit is acting weird for me, I wonder if it has to do with the CDN migration stuff
[19:56:23] <inflatador>	 +1'd the above
[22:08:52] <pfischer>	 ebernhardson: It was my understanding, that OpenSearch is configured to reach out to LiftWing to get the query-vector. CirrusSearch should not have to do that.