The WDQS proxy should return useful error messages (ideally in json format) when an error occurs. This includes:
AC:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | gmodena | T422522 WE2.5.8 WDQS v2 technical build | |||
| Resolved | lerickson | T424218 wdqs-proxy: Improved error handling apart from HTTP response codes |
lerickson updated https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/37
Draft: Map error messages from BadRequestExceptions into a json response
lerickson merged https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/37
Add structured JSON errors to HTTP 400s from the proxy.
lerickson opened https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/40
wdqs-proxy: Map HTTP 500 Internal Server Error to JSON as well
lerickson merged https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/40
Map HTTP 500 Internal Server Error to JSON payloads as well
I've been investigating to see which errors can be returned from qlever. I actually could not find documentation about this, but searching the code worked pretty well.
The easiest thing seemed to be to grep the repo for "http::status::" and see what came up, and restrict to the 4xx/5xx ones. Based on this search, I think that these are the possible errors returned by qlever:
400 Bad Request
403 Forbidden
404 Not Found
406 Not Acceptable
409 Conflict
415 Unsupported Media Type
429 Too Many Requests
500 Internal Server Error
Some of them we should propagate as-is (we might need to do some work to retain the message); some we might want to remap inside the proxy.
429 Too Many Requests is an interesting one; it was added here: https://github.com/ad-freiburg/qlever/commit/82849e6e2bc60ea8ed7c0fbe9b5a55966caebe11 and seems to convey that the backend will be available again soon when indexing is over, but doesn't seem exactly semantically correct from our point of view (503 seems better?). However, I think our plan was to depool the nodes while this is happening anyway, so it shouldn't be an issue (but I'll sync with the team on that).
Update on these error codes. I believe that we don't need to worry about many of them.
400 Bad Request: Yes, this is relevant
403 Forbidden: No, this means one needs access tokens to override server configs (code) and I don't believe we are exposing anything like this
404 Not found: Yes
406 Not acceptable: No, we will always send a valid Accept header
409 Conflict: No, this means you passed in a query-ID already in use, but we won't do that
415 Unsupported media type: Probably No, This is the Graph Store HTTP protocol; I don't believe we are exposing this either but it's worth verifying
429 Too many requests: Yes, this is returned for timeouts
500 Internal Server Error: Yes
So the ultimate list is: 400, 404, maybe 429, and 500.
lerickson updated https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/41
Map backend errors to structured responses.
lerickson merged https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/41
Map backend errors to structured responses.
lerickson updated https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/44
Draft: Return an error from the BlazegraphHintHandler
lerickson merged https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/44
Delete the BlazegraphHintHandler
lerickson opened https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-proxy/-/merge_requests/45
Draft: Send events in the proxy