Error identifiers / translations

[chladog]

I'm having a multilingual setup and wonder if there is any way how to provide translation for error messages returned by GraphQL based on locale.
I need to show users error messages in appropriate locale.
For example returned error object:

{
  "errors": [
    {
      "message": "The following field is invalid: email",
      "data": [
        {
          "message": "A user with the given username is already registered",
          "field": "email"
        }
      ]
    }
  ],
  "data": {
    "createUser": null
  }
}

even without providing translation by the server right away which is preferable, the translation could be provided by the client app, but there is no simple identifier of the error code to pair it with, like error code or simple error string "ERR_USER_ALREADY_EXISTS". I don't want to pair it with error messages as they can change in the future.

The error codes/ids would be helpful also for handling different errors on client-side differently (e.g. show different image, colors, different retry strategy etc.)

I'm also having an additional problem with this that errors live in different separate object from the query object, which also behave buggy, most importantly makes multiple queries/mutations in single request tricky. I'll create a separate ticket for this.

Any suggestions?

[DanRibbens]

I like the idea of building out error types as a new feature enhancement. I need to do some more research on this and get back to you.

[DanRibbens]

We have a pattern for throwing errors in Payload and we could go through and give them all codes and return them in the error responses. I like this improvement and it would be helpful for anyone writing better custom error handlers that can be more extensible too, not just for frontend uses.

If we just add a code property to APIError and send the code through, would that cover your use case here?
Here are all the errors we have defined, of course more can be added too: https://github.com/payloadcms/payload/tree/master/src/errors

We could also add transaltions to our messages at some point too, but I think the code concept would be helpful too and more customizable.

How does that sound to you @chladog?

[chladog]

Yes, having error codes in the response would be the minimum needed.
If I understand correctly by "writing better custom error handlers" you mean that on the client side, however why not to allow to pass into Payload.config customErrorHandler function (or ErrorFilter) that would allow us actually change the default response JSON - for example changing messages based on context or locale, adding custom data etc. This would make everything maintainable and client-side error handling nicely light without possibly hundreds translation strings that mostly won't ever be seen.

So the ErrorFilter would sit in src/graphql/errorHandler.ts if exists taking in response and returning modifiedResponse and passing it along.

The config would look smth like this

{
  serverURL: "http://localhost:3000",
  ...
  errorFilter: (response: defaultResponseObj, {context: {req, doc, originalDoc...}}) => {
      const modifiedResponse = Object.assign({}, response);      // *
            switch (modifiedResponse.code) {
            case 4:
                modifiedResponse.message = req.locale === 'cs' ? 'My error message in Czech' :  modifiedResponse.message;
                break;
            case 6:
                myAdditionalData = originalDoc.title;
                modifiedResponse.data= {...modifiedResponse.data, oldTitle: myAdditionalData}
                ...
            ...
        }
    return modifiedResponse;
    },
    ...
}
// * probably better to make copy so in src/graphql/errorHandler.ts can run some kind of validation against the schema - if invalid discard modified and continue with original response

[DanRibbens]

I didn't mean custom error handlers for the frontend. I was talking about our afterError hook which I am realizing now is not documented at all!

The afterError hook is called anytime the server encounters an error and exists so that you can add code that would help diagnose problems, notify sysadmins, or modify responses to the frontend.

From this conversation I'm realizing it isn't being called with req and there is a bug in that the return response is ignored in our graphql error handling preventing you from overriding the response message. With that bug fixed and changing the args for afterHook, you'd be able to do this. I think that is the right way forward.

[chladog]

Aah, I see. I was searching for error handling in the docs and didn't find anything. Great that this feature exists and is exactly what I'm looking for. So once the bug is fixed and context extended everything's perfect!