Closed atzedus closed 1 year ago
Hi @atzedus thanks for the PR, looks good, would you mind posting an example though so I can see which paths you mean?, Do you mean the path in the returned error is the path in the subquery, instead of the original query?
Hi, @pkqk
For example, the schema is:
scalar Time
input orderData {
delivery_on: Time!
}
type Mutation {
orderCreate(data: orderData!) Boolean!
}
Then, if i querying service directly
mutation OrderCreate {
orderCreate(
data: {
delivery_on: "invalid_time_format"
}
)
}
the response is:
{
"errors": [
{
"message": "parsing time \"invalid_time_format\" as \"2006-01-02T15:04:05.999999999Z07:00\": cannot parse \"invalid_time_format\" as \"2006\"",
"path": [
"OrderCreate",
"data",
"delivery_on"
]
}
],
"data": {
"OrderCreate": false
}
}
But if i querying through bramble as federated service, the response is:
{
"errors": [
{
"message": "parsing time \"invalid_time_format\" as \"2006-01-02T15:04:05.999999999Z07:00\": cannot parse \"invalid_time_format\" as \"2006\"",
"path": [
"OrderCreate"
],
"locations": [
{
"line": 2,
"column": 3
}
],
"extensions": {
"selectionSet": "{ OrderCreate(data: {delivery_on:\"invalid_time_format\") }",
"serviceName": "useroffice",
"serviceUrl": "http://useroffice:5000/api"
}
}
],
"data": {
"OrderCreate": false
}
}
The full path of error in the "path" key is lost.
When federated service response contains graphql error with provided "Path" the bramble override this with it own internal "path" and we lost this information. This pull request will fix it.