Page MenuHomePhabricator

wdqs-proxy error with simple query
Closed, ResolvedPublic

Description

The Sparql Query:

SELECT ("x" AS ?x) WHERE {}

Is accepted by the Blazegraph query server ( https://query.wikidata.org / https://query.wikidata.org/sparql ) and by the QLever test server ( https://qlever.dev ), but rejected by the new server deployment ( https://query-next.wikidata.org / https://query-next.wikidata.org/sparql ) with the error:

Invalid SPARQL query: Unexpected end of input: mismatched input '<EOF>' expecting {'{', WHERE, FROM}

at 18:1 of the rewritten query:


^

rewritten query:

PREFIX  schema: <http://schema.org/>
PREFIX  bd:   <http://www.bigdata.com/rdf#>
PREFIX  ps:   <http://www.wikidata.org/prop/statement/>
PREFIX  wdt:  <http://www.wikidata.org/prop/direct/>
PREFIX  wikibase: <http://wikiba.se/ontology#>
PREFIX  mwapi: <https://www.mediawiki.org/ontology#API/>
PREFIX  xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX  skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX  rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX  wd:   <http://www.wikidata.org/entity/>
PREFIX  p:    <http://www.wikidata.org/prop/>
PREFIX  rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX  hint: <http://www.bigdata.com/queryHints#>
PREFIX  wdno: <http://www.wikidata.org/prop/novalue/>
PREFIX  entity: <http://www.wikidata.org/entity/>

SELECT  ("x" AS ?x)

Expected Behaviour
The query runs the same in both QLever and Blazegraph deployments and returns the result x.
It seems the rewritten query drops the {} from the end of the query, causing the query to fail to parse. The error can also reproduced when running the QLever server and wdqs-proxy on a local developer machine.

Event Timeline

For context, a query of this form is used in WikibaseQualityConstraints to run regex constraint checks using the query service. (Though this feature is disabled in production in favor of using shellbox – see the $wgWBQualityConstraintsFormatCheckerShellboxRatio config – so I guess it doesn’t really block the migration of WBQC to QLever in production. But for a time, the query service was the best way we had to run regex checks with a time limit in order to protect against ReDOS attacks.)

trueg changed the task status from Open to In Progress.Aug 11 2026, 2:40 PM
trueg claimed this task.

The proxy now properly handles the special case of an empty query body. Where it previously simply dropped the body entirely, it will now add en empty body, ie. {}.