Batch update returns non-indexed errors

When running a mutation with multiple inputs, the response contains a slice of error strings that do not respect the index of requested mutations and it can be messy to track the transaction that resulted in an error.

For instance:

mutation AddPages { addPage(input: [ { Id: "1", ... }, { Id: "2", ...}, { Id: "3" ...} ] ) { numUids } }

If I already have Ids 1 and 3 in the database, we’re gonna get two errors as expected:

{ "errors": [ { "message": "couldn't rewrite query for mutation addPage because id 1 already exists for type Page" }, //id 2 was added, but errors are sequencial and have no identifier of problematic instruction { "message": "couldn't rewrite query for mutation addPage because id 3 already exists for type Page" } ], "data": { "addPage": { "numUids": 1 } }, "extensions": {... }, "queryCost": 1 } }

There are two errors but I don’t know which input generated them. I could make a regex to track which are the IDs mentioned but it would be much easier if I could link the error to one of the inputs I’ve provided.

Is there a way of doing that?

2 Likes

We do return the path for an error for a query but seems like that doesn’t happen for addT mutations. We should return the index of the original array where the error occurred. Accepting this as an improvement.

1 Like