Hi @dr0ptp4kt, is this ticket waiting on any action from our team? (We are currently reviewing the tickets on our board and were wondering about this)

HI @ItamarWMDE . The task got auto-tagged for Search Platform triage based on its early tags, so it got visibility while going through the backlog last week. It's moved to the Blocked/Waiting column on the Search Platform's board, with the understanding that the probable next step is for the Wikidata team (and Search Platform can be looped for any necessary code review). Now, this said, is there any dependency from the Wikidata team for Search Platform?

If it might make sense to schedule a one-off call to verify any next actions, I'm all for it - please do advise. Thanks!

CC @dcausse

Oh, I see. Yeah, I wasn't sure who was picking this up because of all the tags and board movements. In that case, we'll review it again the next time we prioritize our tasks. Thank you!

In T374021#10180398, @dr0ptp4kt wrote:

It's moved to the Blocked/Waiting column on the Search Platform's board, with the understanding that the probable next step is for the Wikidata team (and Search Platform can be looped for any necessary code review). Now, this said, is there any dependency from the Wikidata team for Search Platform?

I think there are two or three steps here with different responsibilities:

1. Bring up the internal split endpoints.
2. Add Envoy proxies for them (if needed?).
3. Update the production config.

We can do step 3, but I think we currently expect that Search Platform will do step 1 (and from the subtasks it sounds like you’re working on it). I have no idea about step 2 in between, but I think step 1 is a first requirement in any case. Does that make sense? (If yes, that means there’s nothing for the Wikidata team to do at the moment.)

@Lucas_Werkmeister_WMDE I realized there was a question in here, apologies for the delayed response. Yes, that makes sense. This said, I'll hand this task over to @Gehel for any additional actioning re: T376150: Prepare hosts to serve wdqs-internal-main & wdqs-internal-scholarly T376151: Cutover wdqs-internal to new split endpoints and any potential need for proxy/load balancing pieces in case any new discrete task should be written up there as well.

In T374021#10217056, @Lucas_Werkmeister_WMDE wrote:

In T374021#10180398, @dr0ptp4kt wrote:

It's moved to the Blocked/Waiting column on the Search Platform's board, with the understanding that the probable next step is for the Wikidata team (and Search Platform can be looped for any necessary code review). Now, this said, is there any dependency from the Wikidata team for Search Platform?

I think there are two or three steps here with different responsibilities:

1. Bring up the internal split endpoints.
2. Add Envoy proxies for them (if needed?).
3. Update the production config.

We can do step 3, but I think we currently expect that Search Platform will do step 1 (and from the subtasks it sounds like you’re working on it). I have no idea about step 2 in between, but I think step 1 is a first requirement in any case. Does that make sense? (If yes, that means there’s nothing for the Wikidata team to do at the moment.)

Step 1 is being worked on now (as will step 2).

We'll work with WMDE on step 3 (changing the mediawiki-config etc).

Currently there's one thing I'm uncertain about, which is whether we ultimately need a separate wdqs-internal service for both wdqs-main and wdqs-scholarly or whether just wdqs-main suffices. Who would be the best point of contact for understanding how wdqs-internal is actually queried from mediawiki currently? Or a more clear question would be: do we know if the parts of the graph that are now wdqs-scholarly are relevant at all for Mediawiki's usage of wdqs-internal or is it only querying stuff that now exists on wdqs-main?

cc @dr0ptp4kt @dcausse for general visibility and also just in case you guys have any ideas here

In T374021#10261031, @RKemper wrote:

Currently there's one thing I'm uncertain about, which is whether we ultimately need a separate wdqs-internal service for both wdqs-main and wdqs-scholarly or whether just wdqs-main suffices. Who would be the best point of contact for understanding how wdqs-internal is actually queried from mediawiki currently? Or a more clear question would be: do we know if the parts of the graph that are now wdqs-scholarly are relevant at all for Mediawiki's usage of wdqs-internal or is it only querying stuff that now exists on wdqs-main?

wdqs-scholarly is required for one of the checks done by WikibaseQualityConstraints (T355298) so we need both endpoints in a separate wdqs-internal service. I'm not aware of other usecases internally that might need the scholarly graph.

In T374021#10261658, @dcausse wrote:

wdqs-scholarly is required for one of the checks done by WikibaseQualityConstraints (T355298) so we need both endpoints in a separate wdqs-internal service. I'm not aware of other usecases internally that might need the scholarly graph.

Agreed.

We've got both wdqs-internal-main and wdqs-internal-scholarly live in LVS now. So next step (hopefully first half of next week) is to cutover to these new services and then we can start tearing down the old wdqs-internal lvs plumbing once that's not being used anymore.

Change #1105879 had a related patch set uploaded (by Stevemunene; author: Stevemunene):

[operations/mediawiki-config@master] Make WikibaseQualityConstraints use split-graph query service

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

Change #1105879 merged by jenkins-bot:

[operations/mediawiki-config@master] Make WikibaseQualityConstraints use split-graph query service

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

Mentioned in SAL (#wikimedia-operations) [2025-01-14T14:55:19Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1105879|Make WikibaseQualityConstraints use split-graph query service (T374021)]], [[gerrit:1105878|Make WikimediaCampaignEvents use split-graph query service (T377956)]]

Mentioned in SAL (#wikimedia-operations) [2025-01-14T15:01:26Z] <lucaswerkmeister-wmde@deploy2002> stevemunene, lucaswerkmeister-wmde: Backport for [[gerrit:1105879|Make WikibaseQualityConstraints use split-graph query service (T374021)]], [[gerrit:1105878|Make WikimediaCampaignEvents use split-graph query service (T377956)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

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

[operations/mediawiki-config@master] Revert "Make WikibaseQualityConstraints use split-graph query service"

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

Change #1111253 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert "Make WikibaseQualityConstraints use split-graph query service"

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

Mentioned in SAL (#wikimedia-operations) [2025-01-14T15:15:38Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1111253|Revert "Make WikibaseQualityConstraints use split-graph query service" (T374021)]], [[gerrit:1105878|Make WikimediaCampaignEvents use split-graph query service (T377956)]]

Unfortunately it looks like T369079 wasn’t enough, we’ll have to patch the code some more. Currently, the queries in findEntitiesWithSameStatement() and findEntitiesWithSameQualifierOrReference() assume that the subject entity can be found in the graph that we’re querying:

SELECT DISTINCT ?otherEntity WHERE {
  BIND(wds:$guidForRdf AS ?statement)
  BIND(p:$pid AS ?p)
  BIND(ps:$pid AS ?ps)
  ?entity ?p ?statement.
  ?statement ?ps ?value.
  ?otherStatement ?ps ?value.
  ?otherEntity ?p ?otherStatement.
  FILTER(?otherEntity != ?entity)
  MINUS { ?otherStatement wikibase:rank wikibase:DeprecatedRank. }
  $finalSeparatorFilter
}
LIMIT 10

I believe it was originally done this way so that we didn’t have to implement serializing the statement value into the query (though later I added getRdfLiteral() anyway, which we should definitely remove and instead use Wikibase’s RdfBuilder infrastructure). But this doesn’t work for a split query service. We need to refactor the query to not rely on the original entity, and instead directly serialize the statement value into it after all.

Mentioned in SAL (#wikimedia-operations) [2025-01-14T15:21:44Z] <lucaswerkmeister-wmde@deploy2002> stevemunene, lucaswerkmeister-wmde: Backport for [[gerrit:1111253|Revert "Make WikibaseQualityConstraints use split-graph query service" (T374021)]], [[gerrit:1105878|Make WikimediaCampaignEvents use split-graph query service (T377956)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

In T374021#10458231, @Lucas_Werkmeister_WMDE wrote:

I believe it was originally done this way so that we didn’t have to implement serializing the statement value into the query (though later I added getRdfLiteral() anyway, which we should definitely remove and instead use Wikibase’s RdfBuilder infrastructure). But this doesn’t work for a split query service. We need to refactor the query to not rely on the original entity, and instead directly serialize the statement value into it after all.

Yes relying on the presence of the entity data on the sparql service is generally not a good idea because the constraint (depending on when it's checked) might be missed if the entity is not updated in due time.
I agree that a better approach would be to collect all statements from the entity as seen by wikibase and use them in the query. This would fix the behavior you saw when adding duplicated external IDs across both graphs but also would workaround issues related to WDQS not being up to date.

Mentioned in SAL (#wikimedia-operations) [2025-01-14T15:31:41Z] <lucaswerkmeister-wmde@deploy2002> Finished scap sync-world: Backport for [[gerrit:1111253|Revert "Make WikibaseQualityConstraints use split-graph query service" (T374021)]], [[gerrit:1105878|Make WikimediaCampaignEvents use split-graph query service (T377956)]] (duration: 16m 03s)

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

[mediawiki/extensions/WikibaseQualityConstraints@master] Somewhat improve RdfVocabulary usage in SparqlHelper

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

Change #1118120 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Somewhat improve RdfVocabulary usage in SparqlHelper

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

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

[operations/mediawiki-config@master] Reapply "Make WikibaseQualityConstraints use split-graph query service"

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

Change #1127516 merged by jenkins-bot:

[operations/mediawiki-config@master] Reapply "Make WikibaseQualityConstraints use split-graph query service"

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

Mentioned in SAL (#wikimedia-operations) [2025-03-13T14:47:00Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1127462|Enable SUL3 signup for everyone (T384218)]], [[gerrit:1127505|Set $wgSul3RolloutUserPercentage on some testwikis (T384153)]], [[gerrit:1127516|Reapply "Make WikibaseQualityConstraints use split-graph query service" (T374021)]]

Mentioned in SAL (#wikimedia-operations) [2025-03-13T14:50:00Z] <lucaswerkmeister-wmde@deploy2002> tgr, lucaswerkmeister-wmde: Backport for [[gerrit:1127462|Enable SUL3 signup for everyone (T384218)]], [[gerrit:1127505|Set $wgSul3RolloutUserPercentage on some testwikis (T384153)]], [[gerrit:1127516|Reapply "Make WikibaseQualityConstraints use split-graph query service" (T374021)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-03-13T14:57:24Z] <lucaswerkmeister-wmde@deploy2002> Finished scap sync-world: Backport for [[gerrit:1127462|Enable SUL3 signup for everyone (T384218)]], [[gerrit:1127505|Set $wgSul3RolloutUserPercentage on some testwikis (T384153)]], [[gerrit:1127516|Reapply "Make WikibaseQualityConstraints use split-graph query service" (T374021)]] (duration: 10m 24s)

The split graph was working in WikimediaDebug as far as I could tell (I temporarily added conflicting IDs of this minor paper to the sandbox and sandbox 2 items and both were reported correctly). \o/

@Lucas_Werkmeister_WMDE Anything else needed from us? Should we close this task?

Per https://grafana.wikimedia.org/d/000000489/wikidata-query-service?orgId=1&refresh=1m&var-cluster_name=wdqs-internal&var-graph_type=%289102%7C919%5B35%5D%29 it looks like traffic is cut over as expected. Awesome work everybody!

In T374021#10643668, @Gehel wrote:

@Lucas_Werkmeister_WMDE Anything else needed from us? Should we close this task?

I don’t think so, it’s just waiting for tech verification from our side :)