Change #1080043 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/EntitySchema@master] WIP: Define search fields for CirrusSearch

https://gerrit.wikimedia.org/r/1080043

Change #1080046 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/EntitySchema@master] WIP: Use WikibaseCirrusSearch fields

https://gerrit.wikimedia.org/r/1080046

Change #1080050 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[integration/config@master] Zuul: [mediawiki/extensions/EntitySchema] Add Elastica+CirrusSearch phan deps

https://gerrit.wikimedia.org/r/1080050

Change #1080050 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/EntitySchema] Add Elastica+CirrusSearch phan deps

https://gerrit.wikimedia.org/r/1080050

We should try to re-use the existing labels field declared in WikibaseCirrusSearch, adding yet another multi-lang field should be avoided because it's quite costly and caused much troubles on third parties install like wikibase.cloud.
The current approach for defining fields and providing the fields data is sadly bit counter intuitive for re-using fields because both functions are attached to the ContentHandler.

I think https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EntitySchema/+/1080046 is what I would prefer but I wonder if we couldn't adapt/move this code to WikibaseCirrusSearch and make EntitySchema a dependency of WBCS instead of introducing a strong coupling the other way around. Could we possibly re-use the same injection technique that we have for EntityHandler that receives a FieldDefinitions?

This could be decided at runtime by WikibaseSearch.entitytypes.php declaring \Wikibase\Search\Elastic\Fields\LabelsProviderFieldDefinitions for entity schemas or some similar injection mechanism?

We then have to make all the three fields defined with WBCS:

• LabelCountField
• LabelsField
• AllLabelsField

compatible with entity schema. This is where we might still need a hack because EntitySchemaContent/FullViewEntitySchemaData is not an EntityDocument but we could possibly introduce a new interface like LabelsProviderFieldData in wikibase/repo declaring a method getLabelsFieldData( LabelsProdiver $labels ): mixed and have the 3 Field classes above implementing it.
EntitySchemaContentHandler could then be somewhat Cirrus agnostic with:

	public function getDataForSearchIndex(
		WikiPage $page,
		ParserOutput $parserOutput,
		SearchEngine $engine,
		RevisionRecord $revision = null
	) {
		$fieldsData = parent::getDataForSearchIndex( $page, $output, $engine, $revision );
		$content = $revision !== null ? $revision->getContent( SlotRecord::MAIN ) : $page->getContent();
		if ( $content instanceof EntitySchemaContent ) {
			$viewData = ( new EntitySchemaConverter() )
				->getFullViewSchemaData( $content->getText(), [] );

			$fields = $this->fieldDefinitions->getFields();

			foreach ( $fields as $fieldName => $field ) {
            	            if ( $field instanceof LabelsProviderFieldData ) {
				$fieldsData[$fieldName] = $field->getLabelsFieldData( $viewData ); // this assumes we make FullViewEntitySchemaData implements LabelsProvider or we could create an adapter class? 
                 	    }
			}
		}
		return $fieldsData;
	}

I didn’t even know about LabelCountField. As far as I can tell, it’s not used for anything – I’m not seeing any meaningful references to label_count or LabelCountField::NAME, neither in the current code nor in the git log -S. From the change that introduced it, it sounds like it was added just in case it was useful for the search scoring (by analogy with sitelink_count / SitelinkCountField and statement_count / StatementCountField: the former is actually used for scoring, the latter is at least returned in the EntityResult); but if we haven’t actually used it in almost nine years, maybe it’s time to just drop it?

In T376250#10226708, @dcausse wrote:

I wonder if we couldn't adapt/move this code to WikibaseCirrusSearch and make EntitySchema a dependency of WBCS instead of introducing a strong coupling the other way around.

Most Wikibase users will want to use WikibaseCirrusSearch, but only a tiny fraction of them will want to use EntitySchema, so making WBCS depend on EntitySchema doesn’t sound like a good idea to me.

Could we possibly re-use the same injection technique that we have for EntityHandler that receives a FieldDefinitions?

This could be decided at runtime by WikibaseSearch.entitytypes.php declaring \Wikibase\Search\Elastic\Fields\LabelsProviderFieldDefinitions for entity schemas or some similar injection mechanism?

I doubt it, because we are stuck with an architectural decision that EntitySchema should not use Wikibase entity registration (even though I and other developers have repeatedly argued against this decision).

What would be the benefit of this, compared to just hard-coding LabelsField and AllLabelsField in EntitySchemaContentHandler?

We then have to make all the three fields defined with WBCS:

• LabelCountField
• LabelsField
• AllLabelsField

compatible with entity schema. This is where we might still need a hack because EntitySchemaContent/FullViewEntitySchemaData is not an EntityDocument but we could possibly introduce a new interface like LabelsProviderFieldData in wikibase/repo declaring a method getLabelsFieldData( LabelsProdiver $labels ): mixed and have the 3 Field classes above implementing it.

I don’t really like the sound of making EntitySchema implement LabelsProvider while we don’t have a proper EntitySchemaDocument-like class, and I think this is also basically prohibited by the same architectural decision mentioned above.

What would be the benefit of this anyways, compared to directly populating the field data in EntitySchemaContentHandler::getDataForSearchIndex() (as implemented in this change)? The only one I can think of is that it avoids implementing the structure of the field in two places; but given that the structure is pretty straightforward ([ 'labels' => [ $languageCode => [ $label, ...$aliases ] ] ]) and seems unlikely to change, I’m not sure this is really a big problem. I think I’d be content with some tests for this and a comment in LabelsField::getFieldData() pointing out the other implementation.

One thing I’m noticing: WikibaseCirrusSearch checks whether $engine instanceof CirrusSearch as part of getFieldsForSearchIndex() (in TermIndexField::getMappingField() – for other engines, the fields aren’t registered), but not as part of getDataForSearchIndex(): as far as I can tell, LabelsField::getFieldData() will always return the field data whether the engine is CirrusSearch or something else. Is that important? (Codesearch looks like CirrusSearch might be the only “real” caller of getDataForSearchIndex() anyways, so perhaps not.)

In T376250#10228472, @Lucas_Werkmeister_WMDE wrote:

[...] but if we haven’t actually used it in almost nine years, maybe it’s time to just drop it?

No objections to drop it, I think it dates back from an idea expressed at T110648#1811494 but looks like we never actually started using it.

---

In T376250#10226708, @dcausse wrote:

I wonder if we couldn't adapt/move this code to WikibaseCirrusSearch and make EntitySchema a dependency of WBCS instead of introducing a strong coupling the other way around.

Most Wikibase users will want to use WikibaseCirrusSearch, but only a tiny fraction of them will want to use EntitySchema, so making WBCS depend on EntitySchema doesn’t sound like a good idea to me.

I think to follow the same pattern we have so far where wikibase components do not depend on CirrusSearch but it's the other way around:

• Wikibase <- WikibaseCirrusSearch
• Wikibase <- (WikibaseCirrusSearch, WikibaseLexeme) <- WikibaseLexemeCirrusSearch

here I did not suggest to create yet another extension because this might be too early (see T190022 for why WBCS was extracted out of Wikibase in the first place).
From a practical POV if EntitySchema starts to have complex search functionalities depending of WBCS this is where I'm afraid that putting all this in EntitySchema might not be ideal (esp. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EntitySchema/+/1080045 which introduces a very strong coupling to WBCS). But I'm unclear how you plan to expose this new search? Will it be via wbsearchentities?

Could we possibly re-use the same injection technique that we have for EntityHandler that receives a FieldDefinitions?

This could be decided at runtime by WikibaseSearch.entitytypes.php declaring \Wikibase\Search\Elastic\Fields\LabelsProviderFieldDefinitions for entity schemas or some similar injection mechanism?

I doubt it, because we are stuck with an architectural decision that EntitySchema should not use Wikibase entity registration (even though I and other developers have repeatedly argued against this decision).

What would be the benefit of this, compared to just hard-coding LabelsField and AllLabelsField in EntitySchemaContentHandler?

Mainly to limit the dependency between EntitySchema and WikibaseCirrusSearch, going the other way around (but again I'm not yet clear from what API you want to expose this search) I think we might just need a small hook to let WBCS injects the Fields to EntitySchemaContentHandler.

We then have to make all the three fields defined with WBCS:

• LabelCountField
• LabelsField
• AllLabelsField

compatible with entity schema. This is where we might still need a hack because EntitySchemaContent/FullViewEntitySchemaData is not an EntityDocument but we could possibly introduce a new interface like LabelsProviderFieldData in wikibase/repo declaring a method getLabelsFieldData( LabelsProdiver $labels ): mixed and have the 3 Field classes above implementing it.

I don’t really like the sound of making EntitySchema implement LabelsProvider while we don’t have a proper EntitySchemaDocument-like class, and I think this is also basically prohibited by the same architectural decision mentioned above.

What would be the benefit of this anyways, compared to directly populating the field data in EntitySchemaContentHandler::getDataForSearchIndex() (as implemented in this change)? The only one I can think of is that it avoids implementing the structure of the field in two places; but given that the structure is pretty straightforward ([ 'labels' => [ $languageCode => [ $label, ...$aliases ] ] ]) and seems unlikely to change, I’m not sure this is really a big problem. I think I’d be content with some tests for this and a comment in LabelsField::getFieldData() pointing out the other implementation.

This is not only the structure of the field data but also how the fields are constructed in getFieldsForSearchIndex it seems weird for EntitySchema to inspect the config of WBCS.

In T376250#10229091, @Lucas_Werkmeister_WMDE wrote:

One thing I’m noticing: WikibaseCirrusSearch checks whether $engine instanceof CirrusSearch as part of getFieldsForSearchIndex() (in TermIndexField::getMappingField() – for other engines, the fields aren’t registered), but not as part of getDataForSearchIndex(): as far as I can tell, LabelsField::getFieldData() will always return the field data whether the engine is CirrusSearch or something else. Is that important? (Codesearch looks like CirrusSearch might be the only “real” caller of getDataForSearchIndex() anyways, so perhaps not.)

I wonder if doing this check is still necessary? It might have been perhaps useful when this code was part of Wikibase, because CirrusSearch might not be on the classpath extra caution was taken to avoid calling code depending on non installed classes? Now that it's part of WBCS, CirrusSearch must be on the classpath and if this field is returned it must be that WBCS decided to inject it anyways.

Alright, I made T377226 to drop the unused field.

So far I’ve been assuming that it’s okay for EntitySchema to depend directly on CirrusSearch (and WikibaseCirrusSearch), just like WikibaseMediaInfo already does. AFAIK both extensions are relatively unlikely to be used by other Wikibases (unlike WikibaseLexeme, which is why WikibaseLexemeCirrusSearch makes sense). If we want to keep CirrusSearch-specific code out of EntitySchema, IMHO we would have to go for a separate extension (EntitySchemaCirrusSearch, I guess) – I don’t think it belongs in WikibaseCirrusSearch.

The search is meant for wbsearchentities, yes (and with the WIP change from T376252 that part already works). If we reuse the WikibaseCirrusSearch fields, then it seems that the haslabel: and inlabel: keywords for regular search also work for EntitySchema “for free”, but that’s not a requirement at this point, just a nice-to-have.

This is not only the structure of the field data but also how the fields are constructed in getFieldsForSearchIndex it seems weird for EntitySchema to inspect the config of WBCS.

Fair, but to me it seems like an acceptable tradeoff compared to introducing a separate extension for the search code. (Now that I look, it turns out that, again, WikibaseMediaInfo already does this, though using $configFactory->makeConfig( 'WikibaseCirrusSearch' )->get( 'UseStemming' ) rather than $config->get( 'WBCSUseStemming' ) – I should update my change to use that instead of hard-coding the WBCS prefix.)

In T376250#10229230, @dcausse wrote:

In T376250#10229091, @Lucas_Werkmeister_WMDE wrote:

One thing I’m noticing: WikibaseCirrusSearch checks whether $engine instanceof CirrusSearch as part of getFieldsForSearchIndex() (in TermIndexField::getMappingField() – for other engines, the fields aren’t registered), but not as part of getDataForSearchIndex(): as far as I can tell, LabelsField::getFieldData() will always return the field data whether the engine is CirrusSearch or something else. Is that important? (Codesearch looks like CirrusSearch might be the only “real” caller of getDataForSearchIndex() anyways, so perhaps not.)

I wonder if doing this check is still necessary? It might have been perhaps useful when this code was part of Wikibase, because CirrusSearch might not be on the classpath extra caution was taken to avoid calling code depending on non installed classes? Now that it's part of WBCS, CirrusSearch must be on the classpath and if this field is returned it must be that WBCS decided to inject it anyways.

I thought the check was intended for a situation where WikibaseCirrusSearch is installed but not used. AFAIK you can get that today (and it’s even the default if you don’t set $wgSearchType and $wgWBCSUseCirrus), though that just means you get a search that doesn’t work very well. The check could also be there to support other “advanced” searches that aren’t based on CirrusSearch / Elasticsearch, but AFAIK that’s just a hypothetical concern (I’m not aware of any other good search extensions).

In T376250#10229931, @Lucas_Werkmeister_WMDE wrote:

So far I’ve been assuming that it’s okay for EntitySchema to depend directly on CirrusSearch (and WikibaseCirrusSearch), just like WikibaseMediaInfo already does. AFAIK both extensions are relatively unlikely to be used by other Wikibases (unlike WikibaseLexeme, which is why WikibaseLexemeCirrusSearch makes sense). If we want to keep CirrusSearch-specific code out of EntitySchema, IMHO we would have to go for a separate extension (EntitySchemaCirrusSearch, I guess) – I don’t think it belongs in WikibaseCirrusSearch.

WikibaseMediaInfo is a bit special and has grown quite big because of MediaSearch, I think it would have make sense to externalize the cirrus bits at some point because WikibaseMediaInfo is now heavily entangled with CirrusSearch and probably does not work without it. It's fine for extensions to depend on Cirrus if they do light customisations (adding a field + a search keyword), if they do more by implementing a search query builder they're more likely to break when cirrus changes, we tried but we don't have a well designed API with a clear separation of what is public vs what is internal. It's also harder for you test/use this extension with/without CirrusSearch but as I understood you're fine with this. For us (search platform) it's another extension to watch for breaking changes so its test suite must be run on cirrus CI.

Initially I thought that the base Wikibase model would be enough abstraction to do the customisation you need in WBCS, this is apparently not the case. Creating yet another extension does not seem justified to me at this point but I think we should be cautious of this if the complexity grows and reconsider this decision in the future to avoid the situation we have with WikibaseMediaInfo.

[...]
Fair, but to me it seems like an acceptable tradeoff compared to introducing a separate extension for the search code. (Now that I look, it turns out that, again, WikibaseMediaInfo already does this, though using $configFactory->makeConfig( 'WikibaseCirrusSearch' )->get( 'UseStemming' ) rather than $config->get( 'WBCSUseStemming' ) – I should update my change to use that instead of hard-coding the WBCS prefix.)

sigh... this means we did not get this quite right in the first place and WBCS fields re-use is not as easy as I imagined even when using Wikibase *.entitytypes.php discovery mechanism, I don't like to say because X is doing it it's fine to do it again for Y but I must admit that WBCS is missing something here...

[...]
I thought the check was intended for a situation where WikibaseCirrusSearch is installed but not used. AFAIK you can get that today (and it’s even the default if you don’t set $wgSearchType and $wgWBCSUseCirrus), though that just means you get a search that doesn’t work very well. The check could also be there to support other “advanced” searches that aren’t based on CirrusSearch / Elasticsearch, but AFAIK that’s just a hypothetical concern (I’m not aware of any other good search extensions).

I'm not sure either, it's very likely that this approach is completely broken if multiple competing search engines are installed (which was the case when cirrus was first tested live). We should certainly not try to solve this now but imo doing the instance of check in getMappingField is a design smell, it's way too late, these fields should not be even be injected/inspected in the first place if the target search engine is not compatible.

In T376250#10233102, @dcausse wrote:

WikibaseMediaInfo is a bit special and has grown quite big because of MediaSearch, I think it would have make sense to externalize the cirrus bits at some point because WikibaseMediaInfo is now heavily entangled with CirrusSearch and probably does not work without it.

Yes, it even declares a dependency on WBCS in its extension.json. (Which is why, for years, I’ve had wfLoadExtension( 'WikibaseCirrusSearch' ) in my LocalSettings.php despite only setting up a local Elasticsearch last week.)

Initially I thought that the base Wikibase model would be enough abstraction to do the customisation you need in WBCS, this is apparently not the case. Creating yet another extension does not seem justified to me at this point but I think we should be cautious of this if the complexity grows and reconsider this decision in the future to avoid the situation we have with WikibaseMediaInfo.

Yes, EntitySchema is intentionally very separate from Wikibase :( I don’t like it either.

sigh... this means we did not get this quite right in the first place and WBCS fields re-use is not as easy as I imagined even when using Wikibase *.entitytypes.php discovery mechanism, I don't like to say because X is doing it it's fine to do it again for Y but I must admit that WBCS is missing something here...

⇒ T377318: Improve WikibaseMediaInfo’s integration with WikibaseCirrusSearch (I feel like the multiple discussion threads here are starting to get out of control 😅)

I'm not sure either, it's very likely that this approach is completely broken if multiple competing search engines are installed (which was the case when cirrus was first tested live). We should certainly not try to solve this now but imo doing the instance of check in getMappingField is a design smell, it's way too late, these fields should not be even be injected/inspected in the first place if the target search engine is not compatible.

Okay… does that mean we shouldn’t do the instanceof check? (I think I’d prefer to keep it for consistency with the other extensions, but I’m also okay with dropping it if you prefer that and it works out at runtime.)

Also, your point about the internal and public interface of WBCS has me coming back to this earlier suggestion…

In T376250#10228472, @Lucas_Werkmeister_WMDE wrote:

… This is where we might still need a hack because EntitySchemaContent/FullViewEntitySchemaData is not an EntityDocument but we could possibly introduce a new interface like LabelsProviderFieldData in wikibase/repo declaring a method getLabelsFieldData( LabelsProdiver $labels ): mixed and have the 3 Field classes above implementing it.

I don’t really like the sound of making EntitySchema implement LabelsProvider while we don’t have a proper EntitySchemaDocument-like class, and I think this is also basically prohibited by the same architectural decision mentioned above.

It would be nice if we could find an implementation where LabelsProviderFieldDefinition is the “more public” interface of WBCS, and LabelsField and AllLabelsField are more internal implementation details, and EntitySchema just uses LabelsProviderFieldDefinition to create the fields. I still don’t want to have EntitySchemaContent or FullViewEntitySchemaData implement LabelsProvider directly, but with a separate adapter class I could probably live with it… (IIUC, WBCS “wants” LabelsProviderFieldDefinition to be internal too, but I don’t think that’s feasible without having entity type registration for EntitySchema.)

(Unfortunately, that adapter class would also have to implement EntityDocument to satisfy the getFieldData() parameter type, even though the fields don’t actually use any EntityDocument classes. That’s annoying.)

In T376250#10233177, @Lucas_Werkmeister_WMDE wrote:

⇒ T377318: Improve WikibaseMediaInfo’s integration with WikibaseCirrusSearch (I feel like the multiple discussion threads here are starting to get out of control 😅)

Thanks! I think this is sane to reflect a bit on the mess we created and if there are easy cleanups we could make we should consider them and I very much appreciate that you do so! :)

Okay… does that mean we shouldn’t do the instanceof check? (I think I’d prefer to keep it for consistency with the other extensions, but I’m also okay with dropping it if you prefer that and it works out at runtime.)

Sure, let's keep it, it does not hurt much.

---

Also, your point about the internal and public interface of WBCS has me coming back to this earlier suggestion…

In T376250#10228472, @Lucas_Werkmeister_WMDE wrote:

… This is where we might still need a hack because EntitySchemaContent/FullViewEntitySchemaData is not an EntityDocument but we could possibly introduce a new interface like LabelsProviderFieldData in wikibase/repo declaring a method getLabelsFieldData( LabelsProdiver $labels ): mixed and have the 3 Field classes above implementing it.

I don’t really like the sound of making EntitySchema implement LabelsProvider while we don’t have a proper EntitySchemaDocument-like class, and I think this is also basically prohibited by the same architectural decision mentioned above.

It would be nice if we could find an implementation where LabelsProviderFieldDefinition is the “more public” interface of WBCS, and LabelsField and AllLabelsField are more internal implementation details, and EntitySchema just uses LabelsProviderFieldDefinition to create the fields. I still don’t want to have EntitySchemaContent or FullViewEntitySchemaData implement LabelsProvider directly, but with a separate adapter class I could probably live with it… (IIUC, WBCS “wants” LabelsProviderFieldDefinition to be internal too, but I don’t think that’s feasible without having entity type registration for EntitySchema.)

(Unfortunately, that adapter class would also have to implement EntityDocument to satisfy the getFieldData() parameter type, even though the fields don’t actually use any EntityDocument classes. That’s annoying.)

The getFieldData signature is the annoying part, one way I could see this working is:

interface WikibaseLabelsIndexField extends WikibaseIndexField {
   public function getLabelsIndexedData( LabelsProvider $entity ): array;
}

// specialize LabelsProviderFieldDefinitions to return WikibaseLabelsIndexField[]
	/**
	 * @return WikibaseLabelsIndexField[]
	 */
	public function getFields() {...}

class LabelsField extends TermIndexField implements WikibaseLabelsIndexField  {
	/**
	 * @param EntityDocument $entity
	 *
	 * @return mixed Get the value of the field to be indexed when a page/document
	 *               is indexed. This might be an array with nested data, if the field
	 *               is defined with nested type or an int or string for simple field types.
	 */
	public function getFieldData( EntityDocument $entity ) {
		if ( !( $entity instanceof LabelsProvider ) ) {
			return null;
		}
		return $this->getLabelsIndexedData( $entity );
        }

        public function getLabelsIndexedData( LabelsProvider $entity ): array;
		$data = [];
		foreach ( $entity->getLabels() as $language => $label ) {
			$data[$language][] = $label->getText();
		}
		if ( $entity instanceof AliasesProvider ) {
			foreach ( $entity->getAliasGroups() as $aliases ) {
				$language = $aliases->getLanguageCode();
				if ( !isset( $data[$language] ) ) {
					$data[$language][] = '';
				}
				$data[$language] = array_merge( $data[$language], $aliases->getAliases() );
			}
		}
		// Shouldn't return empty arrays, that will be encoded to json as an
		// empty list instead of an empty map. Elastic doesn't mind, but this
		// allows more consistency working with the resulting cirrus docs
		return $data ?: null;
	}
}

// EntitySchemaContentHandler could then call $field->getLabelsIndexedData( $schemaToLabelsAndAliasesAdapter ) ?

please let me know if you think that'd be valuable and I'd be happy to send a few patches.

Splitting off a getLabelsIndexedData() method sounds like a good idea to me so far, but I wonder how EntitySchema would call it. I thought the best case scenario would be for EntitySchema to use LabelsProviderFieldDefinitions, just like WikibaseMediaInfo, and then not even know about the specific fields it returns (LabelsField and AllLabelsField); but then how can EntitySchema call it? Should the method be on some interface implemented by LabelsField (and AllLabelsField), and LabelsProviderFieldDefinitions::getFields() guarantees that it returns an array of that more specific interface and not just any WikibaseIndexField[]? Should EntitySchema do a dynamic has_method() check? Or should it just know about the specific fields after all?

Change #1081187 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/EntitySchema@master] WIP: Use LabelsProviderFieldDefinitions

https://gerrit.wikimedia.org/r/1081187

I updated chain of changes to directly use the WikibaseCirrusSearch classes (instead of bolting that on in a follow-up change) and clean up the code a bit. We’re also going to have a discussion about the architecture with some other team members on Monday.

Change #1080046 abandoned by Lucas Werkmeister (WMDE):

[mediawiki/extensions/EntitySchema@master] WIP: Use WikibaseCirrusSearch fields

Reason:

squashed into I7d2d06f8ea

https://gerrit.wikimedia.org/r/1080046

Change #1081187 abandoned by Lucas Werkmeister (WMDE):

[mediawiki/extensions/EntitySchema@master] WIP: Use LabelsProviderFieldDefinitions

Reason:

squashed into I7d2d06f8ea

https://gerrit.wikimedia.org/r/1081187

Change #1082460 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[integration/config@master] Zuul: [mediawiki/extensions/EntitySchema] Add WikibaseCirrusSearch phan dep

https://gerrit.wikimedia.org/r/1082460

Change #1082460 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/EntitySchema] Add WikibaseCirrusSearch phan dep

https://gerrit.wikimedia.org/r/1082460

Mentioned in SAL (#wikimedia-releng) [2024-11-04T15:01:59Z] <James_F> Zuul: [mediawiki/extensions/EntitySchema] Add WikibaseCirrusSearch phan dep, for T376250