Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle Unknown Exceptions, Process Crashes and provide respective errors with GraphQL #1219

Open
kasvith opened this issue Jan 3, 2023 · 3 comments

Comments

@kasvith
Copy link

kasvith commented Jan 3, 2023

If submitting a bug, please provide the following:

Environment

  • Elixir version (elixir -v): 1.14
  • Absinthe version (mix deps | grep absinthe): 1.7
  • Client Framework and version (Relay, Apollo, etc): None

Expected behavior

Absinthe should provide a formal way to handle unexpected errors, exceptions or process crashes(for example inside DataLoader.KV)
and allow customized errors returned to the GraphQL client.

Actual behavior

Currently, when something goes wrong, we get phoenix default ErrorView. This is bad for even development environments.
GraphQL server should be able to properly reply with a JSON response when some error occurs.

There are community-based blog posts where that tackle this issue

But these blog posts or methods don't work when a process crashes, for example

  • When DataLoader.KV failed due to some issue and crashes the process

I believe this part is crucial for a GraphQL server, I spent hours and days on this issue until I found the above blog posts, but they don't cover the above use cases.

It would be awesome to have some official support to tackle these situations much more swiftly as I believe this is a common problem when working with Absinthe in a production environment

Relevant Schema/Middleware Code

@yurtsiv
Copy link

yurtsiv commented Feb 22, 2023

There's also an issue with queries/mutations over WebSockets, where it falls into a reconnection loop. It could be patched on the client (absinthe-graphql/absinthe-socket#57), but returning proper GraphQL errors from the server is a better solution.

@kasvith
Copy link
Author

kasvith commented Feb 24, 2023

@yurtsiv server should send proper errors.

@Nezteb
Copy link

Nezteb commented Feb 14, 2024

I came to create a similar issue before finding this one, mostly because the docs on the subject ask for contributions: https://hexdocs.pm/absinthe/1.7.6/errors.html 😄

I asked for opinions in the Elixir Slack channel for Absinthe and a few links were shared:

  • One person linked an article related to GraphQL error handling advice in general (not specifically using Elixir/Absinthe)
    • https://productionreadygraphql.com/2020-08-01-guide-to-graphql-errors
    • A second person responded with some critiques on the article's content:
      • "That article, and other similar ones are kinda misleading. I think modeling invalid data in the schema is fine, but explicitly modeling them as 'errors' (Stages 3, 4, 6, and 6a) in that article) is against spec, as the spec is pretty clear that when errors are encountered, there must be an accompanying error in errors."
  • The second person then linked a video, saying "If I could start all over again, I would bake validation and constraint type errors directly into the schema, along the lines of [this video]"

My question to the maintainers: should Absinthe "provide a formal way to handle unexpected errors" as the OP believes? If not, what sort of guidance should live on the docs "errors" page?

cc @maartenvanvliet @bruce since y'all wrote the original requests for assistance 2 and 7 years ago. 😄
screenshot_2024-02-14_at_20 07 14@2x

Regardless of the answer, I'd like to assist!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants