Sat, Jun 9
Fri, Jun 8
Thu, Jun 7
for the record the script to run was:
mwscript extensions/CirrusSearch/maintenance/metastore.php --wiki anywiki --upgrade
Wed, Jun 6
As pointed out by Erik the number of incoming links can sometimes overweight language preferences (this is especially true when using special keywords as they change the scoring formula). I have some hope that can unify the scoring behaviors with and without keywords in the query.
Without any keywords in the query I can see language preference in effect:
Tue, Jun 5
So for now we don't really distinguish between the initial namespaces and the namespaces found in the query.
In the current wikibase situation we fallback to cirrus builder anyways in the presence of keywords so this won't be an issue short term.
Mon, Jun 4
Initially I wanted to change how prefix works by disallowing any changes to the original list of namespace requested from the URL. Sadly this caused many components to fail and I had to revert. I completely agree with you that this behavior makes it difficult for us to make some decisions based on the list of namespaces.
Fixing the root cause by changing the behavior of the prefix: keyword seems hard to achieve in a reasonable amount of time. I'm not saying that it's impossible.
Tue, May 29
Mon, May 28
Fri, May 25
Does it mean that we would make WikbaseClient dependent on CirrusSearch and create all necessary query builders into this client?
Have we considered the possibility to run an actual API call to email@example.com?
I have no clue if the current API output would allow to rebuild TermSearchResult nor if there are perf considerations that make this solution impossible.
Thu, May 24
I started to investigate but yes the 20s shard timeout is not reached before the curl request timeout.
Looking at the stacktrace I failed to see one using the source_regex staying around for long...
Asking elastic to return 0 results (to disable the fetch phase) the time spent is reasonable (20-30sec) and the timeout is properly triggered:
Tue, May 22
May 15 2018
In proposal 2 does it mean we get rid of wgCirrusSearchWriteClusters?
On one hand I like the simplicity of the first proposal but I'd go with something like:
[ NS_FILE => [ 'read_cluster' => 'logical_name_used_by_crosscluster_search' # OR '__local__' if mw-config detects this wiki belongs to the same cluster 'write_clusters' => [ 'eqiad-large-01', 'codfw-large-01', ], 'index_name' => 'commonswiki_file' ];
May 14 2018
@Legoktm no I don't think so, it happens only on patches I cherry pick to this branch. See https://gerrit.wikimedia.org/r/#/c/432984/ a test patch cherry picked from master (succesfull build on the master branch: https://gerrit.wikimedia.org/r/#/c/432981/).
Is it possible that the regression mentioned here is the cause of T194655?
Patch deployed, prefix and associated InputBox forms should work as before.
May 11 2018
@Iniquity sorry about that, the change will be reverted soon, I underestimated the impact of the change and thought that the warning message was sufficient, this was a mistake.