Steps to replicate the issue (include links if applicable):

• Submit an invalid SPARQL query to /sparql and inspect the returned parse_error. Its line number includes prefixes prepended by wdqs-proxy and therefore does not match the submitted query.
• Submit a query that Jena accepts but QLever rejects. Inspect the response: QLever’s JSON body is encoded inside the proxy’s message, and its position refers to the rewritten query rather than the submitted query.
• Trigger an error not covered by ExceptionMappers, such as an unsupported request, and inspect the Quarkus { details, stack } response.

What happens?:

The API returns multiple incompatible error structures. Clients must parse JSON from inside message, handle different details types, and understand Quarkus fallback responses. Some responses can expose stack traces.

Error locations are also unsafe: proxy parse errors include prepended-prefix offsets, while QLever positions refer to a Jena-rewritten query whose lines and tokens may differ from the submitted query. Clients therefore cannot reliably highlight the reported line or column.

What should have happened instead?:

All /sparql failures should use one documented error envelope. Messages should be human-readable, details should always be an object or null, error IDs should have a dedicated field, and stack traces should remain in server logs.

Error positions should either refer to the submitted query or explicitly identify that they refer to the rewritten query. If an original-query position cannot be provided, the response should include the offending token or rewritten-query context.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
N/A

Other information (browser name/version, screenshots, etc.):

Example 1: Proxy parse error reports the wrong line

Input:

SELECT * WHERE {
  ?item     dct:title ?title .
}

Output:

{
  "errorType": "parse_error",
  "message": "Query parse error encountered at line 16, column 13.",
  "details": {
    "line": 16,
    "column": 13
  }
}

Example 2: QLever error is encoded inside message

Input:

SELECT ?x WHERE {
  ?x foo:bar ?y .
}

Output:

{
  "errorType": "bad_request",
  "message": "{\"exception\":\"Invalid SPARQL query: Prefix foo was not registered using a PREFIX declaration\",\"metadata\":{\"line\":2,\"positionInLine\":5,\"startIndex\":23,\"stopIndex\":29},\"query\":\"SELECT ?x WHERE {\\n  ?x foo:bar ?y\\n}\",\"status\":\"ERROR\"}",
  "details": {}
}

Example 3: Federation errors use another details shape

Input:

SELECT * WHERE {
  SERVICE <https://example.org/sparql> {
    ?s ?p ?o .
  }
}

Output:

{
  "errorType": "federation_error",
  "message": "The federation endpoint was rejected.",
  "details": {
    "rejectedEndpoint": "https://example.org/sparql"
  }
}

Example 4: Unhandled errors use the fallback response

Input:

curl -i -X PUT "$WDQS_PROXY_URL/sparql"

Output:

{
  "details": "Error id 67c1ee67-021b-4e66-95b1-7a2d632ae2c9-3",
  "stack": "..."
}