tagged the wrong ticket in the patch, please ignore.

if uris.entity().length() is greater than entityId.length() by 8 char it'll cause this exception. Since it's a test server it's perhaps misconfigured.

Thanks, this worked!
As for codesearch and WikibaseLexemeCirrusSearch I double checked and this project is available.

In T229215#5372539, @Ladsgroup wrote:

Why not fixing WikibaseLexemeCirrusSearch instead of reverting the change? (We searched in codesearch, is WikibaseLexemeCirrusSearch missing there?)

I feel that this guideline is very limiting esp the fact that it prevents to introduce short and isolated contract (e.g. things like LoggerAwareInterface).
For instance how this guideline would apply for things like DestructibleService?

Would a solution using a trait as an adapter to ease the transition be helpful to mitigate the constraints involved by only having a Base class?
Please see: P8791 for a short example
cons:

• more code files

pros:

• BC code isolated to a dedicated trait
• can still implement the interface (and thus multiple ones) as long as you adhere to the BCTrait
• call sites are type hinting with the interface
• the interface remains a clear contract as opposed to a Base class that could rapidly become hard to read.

In T193613#5357929, @Tgr wrote:

I have to extend this type hierarchy but the constructor parameters expected no longer make sense

If you extend a class, it shouldn't matter what the constructor parameters of the original class were. (Unless the class is constructed in code not controlled by you via some non-extensible mechanism, in which case that's your fundamental problem.)

Sorry I came to this task because I face the problem where having an interface used for consumption would have helped a lot. My example is the SearchResult/SearchResultSet objects that a SearchEngine must produce. My problem is:

• SearchResult and SearchResultSet are concrete classes used as type hint all over the place
• I have to extend this type hierarchy but the constructor parameters expected no longer make sense

Is the sole purpose of using abstract classes to give some time for the deprecation process to happen?

Beware that a lot of failures reported as FormatJson::encode($events) failed: Malformed UTF-8 characters, possibly incorrectly encoded. Aborting send. are due to T228496 and relate to sending log events through kafja (these are not MW jobs). These are all search related api requests.
Unless I'm searching incorrectly I can only find 3 instances of this particular failure in the last 7days (ORES RecentChangeSaveHookHandler failing to push due to invalid UTF-8 sequences). Search string I'm using: EventBus AND Malformed NOT "EventBusMonologHandler"

I see that the response is

		<result>
			<binding name='type'>
				<bnode>t1514691780</bnode>
			</binding>
			<binding name='typeLabel'>
				<literal>t1514691780</literal>
			</binding>
		</result>

We could also use mvn -pl -gui which does not require any changes

Failed again (56850851 / 58244355) with:

Reindex task was not successfull: Failed: [{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [803795624]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [854883345]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [562256487]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [894521381]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [825290081]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [894521383]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [825290085]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [894521384]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [854883344]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [854883343]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [803795626]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [803795625]"}},{"shard":-1,"reason":{"type":"search_context_missing_exception","reason":"No search context found for id [825290078]"}}]

In T87781#5325699, @Ladsgroup wrote:

In general, it's better to combine composer dependencies of extension into core using composer merge plugin: https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin

Testing https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/521955 I found that the extension dependencies are not loaded by the php unit boostrap script.
I'm perhaps running this incorrectly (vendor/bin/phpunit extensions/CirrusSearch/tests/phpunit/unit/ or composer phpunit:unit extensions/CirrusSearch/tests/phpunit/unit/).
Loading extensions/*/vendor/autoload.php makes the tests pass for cirrus.

Thanks, we will try to be more cautious on this feature in the future, if there is anything else we can collectively do to improve this I am happy to help otherwise please feel free to close this task as Invalid.

Found https://lists.wikimedia.org/pipermail/qa-alerts/2019-May/date.html#start and https://lists.wikimedia.org/pipermail/qa-alerts/2019-June/date.html#start and indeed the browser test properly failed 6 times consecutively.
I'll start monitoring this particular job but Is there something we can do so that we take actions when it happens again in the future?

The process_cluster_event_timeout_exception is something that can be addressed by increasing the masterTimeout we reverted it back to 30s hoping that the multi-instance cluster setup would help here. Apparently we're still seeing this kind of issue Let's bump this value up to 5m.

@Jdlrobson thanks, I should have looked more closely at jenkins before creating this task. Could someone verify that it actually failed between May 28 and June 2 (jenkins history is too short but hopefully a mail was sent to someone)?

Note however we don't have a field like labels_all for descriptions, right? Also, hascaption is now an alias to haslabel, so they both work on the same field. May be moved to be an alias for hasdescription, of course. But then not clear how hascaption:* would work if at all.

Created T226722 to fix this.

I have no clue why it's not working yet but I think youwe should have indexed the captions to description fields not label fields. Label fields are optimized for exact matches which is not suited for captions.

There is a discrepancy for langues where we do not apply any accent folding. We always apply accent removal (with either asciifolding or icu_folding) on autocomplete and go but we do not on fulltext.
This is inconsistent, I think we should query all_near_match.asciifolding alongside all_near_match for fulltext queries.

it's happening again on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/516637 :

07:16:01 Undefined index: imageinfo
07:16:01 
07:16:01 /workspace/src/extensions/WikibaseMediaInfo/tests/phpunit/integration/WBMIApiTestCase.php:118
07:16:01 /workspace/src/extensions/WikibaseMediaInfo/tests/phpunit/integration/MultiLingualCaptionsTest.php:28
07:16:01 /workspace/src/tests/phpunit/MediaWikiTestCase.php:427

I changed the output to:

{
  "wmfMasterDatacenter": "eqiad",
  "wmfEtcdLastModifiedIndex": 3672,
  "wmgCirrusSearchDefaultCluster": "local",
  "wgCirrusSearchDefaultCluster": "eqiad"
}