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
move graphql error formatting to a function that can be overridden #990
move graphql error formatting to a function that can be overridden #990
Conversation
dad4fc3
to
8498bd1
Compare
A general question first and then a comment specific to this PR. Do you have a motivating example for this case? In this code, if we wanted to swap out the error formatter, it seems like a more common suggestion would be to add a kwarg with a default value to the constructor on the class: class GraphQLApp:
def __init__(
self,
schema: "graphene.Schema",
executor: typing.Any = None,
executor_class: type = None,
graphiql: bool = True,
error_formatter= format_graphql_error
) -> None:
...
self.error_formatter = error_formatter And then to use that attribute to format errors if any are present. This would be more typically Pythonic and more obvious to readers of the code than defining a method that later gets clobbered. Indeed, it seems like this a pattern that graphene uses? I also wonder if this doesn't introduce a potential bug. If |
Error handling between our backend/frontend is done primarily through "error keys" indicating known error cases which the frontend can handle gracefully. These are propagated up through the backend using a custom The current overriding looks like this (requires patching)
I don't have a strong opinion on how the overriding happens, just that it's possible without having to directly patch a graphene import. I can change it to be an optional kwarg if that's the desired way. My reason for breaking it out to a method was that I'm already overriding the majority of the
|
1990290
to
31b3f10
Compare
31b3f10
to
92d9a8b
Compare
Added an optional kwarg to the constructor to override the default |
Thank you for creating this pull request. We have decided to deprecate GraphQL support within Starlette itself so I am going to close this pull request. See #619. |
No description provided.