Page MenuHomePhabricator

Set UA for outgoing requests from Wikibase Cloud's QueryService
Closed, ResolvedPublic

Description

From T395044

We identified that we're probably using the default ua Wikidata Query Service; https://query.wikidata.org/ on cloud.

This should be set to something more cloud specific. It should also ideally contain the version of the query service.

In the short term this should change on Cloud but we should also change the upstream default to something more generic than Wikidata. Perhaps needs changing at https://gerrit.wikimedia.org/g/wikidata/query/rdf/+/097d0f9426c08bb0ff9db6d926052072b2bb35cb/dist/src/script/runBlazegraph.sh#104

Event Timeline

I think setting the USER_AGENT env var in our Dockerfile is worth a try, maybe something like

ENV USER_AGENT="Wikibase.Cloud Query Service; https://wikibase.cloud/"}

I'm trying to inspect the request data by referencing my local queryservice to itself:

PREFIX wbc: <https://testestest.wbaas.dev/entity/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  SERVICE <https://testestest.wbaas.dev/query/sparql> {
    wbc:Q1 rdfs:label ?label 
  }
}

(this also needs importing the local cluster certificate, ideally the queryservice chart and dockerfile should take care of that like we've done it for e.g. quickstatements, but for now here is a oneliner that does the trick POD='queryservice-864bf65566-trdzd'; kubectl cp wikibase-local-ca.crt $POD:/usr/share/ca-certificates/test.crt && kubectl exec -ti $POD -- bash -c 'echo "test.crt" >> /etc/ca-certificates.conf && update-ca-certificates')

excerpt from inspecting platform-nginx logs:

10.244.0.69 - - [17/Jun/2025:11:12:20 +0000] "GET /query/sparql?query=%0Aprefix+dd [...] HTTP/1.1" 200 183 "-" "Wikibase.Cloud Query Service; https://wikibase.cloud/}"

so the environment variable did it's job!

As mentioned in the PR, proposed User Agent string looks like this Wikibase.Cloud Query Service (0.3.135-wmde.13); https://github.com/wbstack/queryservice, where (0.3.135-wmde.13) changes depending on the underlying docker image version.
Feel free to change accordingly of course.

Looks good to me; I was debating for a bit if we would rather put this in the chart, or even in the values in the deploy repository but I think for now it makes most sense to have it here. Not least because you've already done it.

Merged #150 and will deploy in a moment

Took ages to test on staging due to coming across T397522. I can now confirm that it works there. Finally rolling to prod

hrm.. I just also saw something similar on prod to T397522; ran the job again and restarted the QS.

OTOH this is now shipped and I confirmed it worked looking in the controller logs