API: in error JSON, return extensions extra info

[tttp]

Hi,

raised there fixthestatusquo/proca#11

Graphql has a standard error reporting (basically, clear text message), but as well the option to structure it better, eg adding our own error codes so the client can automatically process them

https://blog.atomist.com/error-handling-in-graphql/

So far, the errors I got are "programming" errors, like when I don't send mandatory fields, but we'll have more "user" errors, like signing duplicates or invalid emails or...

Another kind of related issue: some of the errors are potentially async (eg. a bounce email error), would it be crazy to open a websocket to allow to communicate back to the signatory? (it probably doesn't make sense for "only" handling email errors, but what about being able to offer update on the campaigns, like "someone you know just signed from twitter" "your share on whatsapp brought a new signature..."

[marcinkoziej]

We will support error messages conforming to the spec,
so they can have a message that is mostly front-end developer directed, path which is filled by GraphQL runtime with mutation name for instance, and extensions map where we can put what we want, so for instance code and other keys

[tttp]

Is there a way to document (from within graphiql?) the codes that can be returned?

That'd be awesome ;)

[marcinkoziej]

It can be documented in the description of the call, but we should create some document where we will write down what kind of error data we need ( for instance, code may not be enough, perhaps a map of fields->validation error code, or similar).

Error extensions is not part of the GraphQL schema (it's called extensions for a reason). It is not in any way enforced by the GraphQL runtime. It looks like the authors of GraphQL wanted to be agnostic about the shape of error object structure

[tttp]

ok, I suggest to be opportunistic on that one and build it as we go (for now, if you need to put a "non graphql native" error, could you just add it in the doc and we re-evaluate once we have a bunch of use case? I'd suggest to have code that are "url safe", eg "wrong_tld", "duplicate", "unknown_recipient" (ie ascii 7bit, no space, underscore)

…

On Mon, 2 Mar 2020 at 13:21, Marcin Kozey ***@***.***> wrote: It can be documented in the description of the call, but we should create some document where we will write down what kind of error data we need ( for instance, code may not be enough, perhaps a map of fields->validation error code, or similar). Error extensions is not part of the GraphQL schema (it's called extensions for a reason). It is not in any way enforced by the GraphQL runtime. It looks like the authors of GraphQL wanted to be agnostic about the shape of error object structure — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7LKXX67N4GYLKXWDPJTTRFOQDZANCNFSM4K7OEGEA> .