Hi! I'm finally catching up to upgrading to graphene 2.0. A lot of code churn, but there are some nice improvements.
My main complaint at the moment is the noisy logging of graphql errors on execution. I can't find what is logging this to work out how to disable it. Especially in a test suite which is designed to catch errors and verify the messages they have raised, printing a traceback on every test is very unhelpful! I have logging disabled to CRITICAL level when running my test suite.
I'm not sure if this is an issue in Graphene, Graphql core, or graphene-django but I can't find any obvious logging config or stdout writing in any of the projects which would cause it.
Any news on this? I'm having the same issue.
I think this is the logging you're after:
https://github.com/graphql-python/graphql-core/blob/6df8a6312b579a6a1454bcf29a566ce5d0fa9849/graphql/execution/executor.py#L313-L315
This is the only logging in this module, so you can disabled it.
One suggestion I'd make is... at least in development mode for graphene-django, when there's an exception, rather than catching it within the promise executer, and handling it... instead simply throw an exception.
As it is right now, I have to manually set a debugger point within Graphene to catch exceptions before they're handled by the framework.
Ah ha! Thanks @charettes. I hadn't heard of sys.excepthook so didn't know where to look. Should be fixed in the next release of graphql-core.
For anyone else who comes across this, the graphql-core repo (v2) as referenced has been renamed to graphql-core-legacy as the prior name is now used for v3 development. Here is the issue referenced above:
https://github.com/graphql-python/graphql-core-legacy/issues/142
This thread is also useful with concrete information on how to filter the log output.
In particular Manu's comment allows filtering of only GraphQLError exceptions so you can still see unintended exceptions.
Most helpful comment
One suggestion I'd make is... at least in development mode for graphene-django, when there's an exception, rather than catching it within the promise executer, and handling it... instead simply throw an exception.
As it is right now, I have to manually set a debugger point within Graphene to catch exceptions before they're handled by the framework.