Malformed requests are returned as 500s

[goodspark]

Hive Gateway: v2.1.6
Command: supergraph
Configured with persisted documents env vars.
Running locally in Docker.

Request: curl -v POST -H 'Content-Type: application/json' -d '{"documentId": "mytest~0.1.0~"}' localhost:4000/graphql

Response:

< HTTP/1.1 500 Internal Server Error
...
{"errors":[{"message":"Unexpected error.","extensions":{"code":"INTERNAL_SERVER_ERROR"}}]}⏎         

Note the missing persisted document ID (after the second ~). This happens for other invalid requests as well (like missing version or missing app name).

Logs:

ERR [useHiveConsole] [hive] GET https://cdn.graphql-hive.com/artifacts/v1/MY_TARGET_UUID/apps/my_test (x-request-id=e4e2de4c-61a5-403a-acf0-8e0e171ea2d9) failed with status 400 (73ms): {"code":"INVALID_ARTIFACT_TYPE","error":"Invalid artifact type: \"v1\"","description":"Please refer to the documentation for more details: https://docs.graphql-hive.com/features/registry-usage "}
ERR [useHiveConsole] [hive] Abort retry because of status code 400.
ERR 
  stack: "Error: GET https://cdn.graphql-hive.com/artifacts/v1/MY_TARGET_UUID/apps/my_test (x-request-id=e4e2de4c-61a5-403a-acf0-8e0e171ea2d9) failed with status 400.

IMO - this is a bad request error and should be reported as such to the caller of the Gateway. Internal server errors should be reserved for actual crashes in the server code. Generally these are hooked to various metrics/monitors for alerting because they indicate a problem in the code or configuration. However, bad request errors are not strictly always worth alerting on (from the point-of-view of the owner of the gateway service) (unless anomalous), since a bad actor can just spam a public endpoint with garbage and trigger them. Obviously, the caller making the bad requests should alert when they get bad request responses bc that indicates their code or config is bad. But that's not the concern of the Gateway.