When we throw validation errors the http code status is set as 400.
When working with apollo router (in a federated graph) this causes the router to throw additional errors
Specifically
https://www.apollographql.com/docs/graphos/routing/errors#SUBREQUEST_HTTP_ERROR
i.e.
"errors": [
{
"message": "HTTP fetch failed from 'gql-order': 400: Bad Request",
"path": [],
"extensions": {
"code": "SUBREQUEST_HTTP_ERROR",
"service": "gql-order",
"reason": "400: Bad Request",
"http": {
"status": 400
}
}
},
{
"message": "Variable \"$id\" got invalid value \"uuuuu\". invalid format for id",
"extensions": {
"field": "id",
"context": [
{
"arg": "format",
"value": "id
}
],
"code": "BAD_USER_INPUT",
"stacktrace": null
}
}
]
I think the http status we return should probably be a 200 not a 400 because
a. The request isn't actually malformed, we are just throwing an error due to business logic.
b. we don't want to trigger SUBREQUEST_HTTP_ERROR
If you don't fully agree, perhaps we could add an option to the apollo server v4 plugin that allows us to configure that status, and not break current behaviour?
When we throw validation errors the http code status is set as 400.
When working with apollo router (in a federated graph) this causes the router to throw additional errors
Specifically
https://www.apollographql.com/docs/graphos/routing/errors#SUBREQUEST_HTTP_ERROR
i.e.
I think the http status we return should probably be a
200not a400becausea. The request isn't actually malformed, we are just throwing an error due to business logic.
b. we don't want to trigger
SUBREQUEST_HTTP_ERRORIf you don't fully agree, perhaps we could add an option to the apollo server v4 plugin that allows us to configure that status, and not break current behaviour?