feat(orbit): Add Orbit endpoint for named Knowledge Graph queries
What does this MR do and why?
Adds a hidden POST /api/v4/orbit/query/:name endpoint that executes server-defined named queries against the Knowledge Graph gRPC service, instead of clients shipping hard-coded Orbit DSL query strings.
- New Grape endpoint
query/:nameinee/lib/api/orbit/data.rbthat requires a JSON request body (form encoding stringifies nested parameter values, which the per-query parameter schemas reject) and acceptsparameters,response_format, and an optionalsource_type. Gitlab::Workhorse.send_orbit_querygains aquery_type:argument and forwardsQueryType: namedto Workhorse when set.- Workhorse's Orbit
SendQueryinjecter maps the newQueryTypeparam toQUERY_TYPE_NAMEDon the gRPCExecuteQueryRequest, defaulting toQUERY_TYPE_JSONas before.
This moves query definitions to live with the server that runs them, so clients invoke a named, structured operation and can no longer drift from the server's DSL grammar/ontology.
References
Screenshots or screen recordings
Not applicable — backend/API change only.
How to set up and validate locally
-
Ensure the Knowledge Graph gRPC endpoint is configured and the namespace is enabled for Knowledge Graph.
-
Call the endpoint with a JSON body:
curl --request POST \ --header "PRIVATE-TOKEN: <token>" \ --header "Content-Type: application/json" \ --data '{"parameters": {}, "response_format": "raw"}' \ "http://gdk.test:3000/api/v4/orbit/query/<query_name>" -
Verify a non-JSON content type is rejected with
400 JSON request body required (Content-Type: application/json).
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.