graphene-django icon indicating copy to clipboard operation
graphene-django copied to clipboard

Raising exceptions without logging them

Open demeralde opened this issue 5 years ago • 15 comments

Whenever exceptions are raised they're logged in the console (and in Sentry if it's used).

Many of these exceptions are only intended to be shown to the user. For example, django-graphql-jwt raises the PermissionDenied exception for the login_required decorator.

The problem is this pollutes the console output during testing/development and logs unnecessary errors to Sentry. For exceptions such as the example above, that's only intended to be shown to the user.

As a workaround I've tried writing middleware that catches any exceptions thrown:

class ExceptionFilterMiddleware:
    IGNORED_EXCEPTIONS = (
        # Local exceptions
        ValidationException,
        # Third-party exceptions
        JSONWebTokenExpired,
        PermissionDenied,
    )

    def on_error(self, error):
        if not isinstance(error, self.IGNORED_EXCEPTIONS):
            return error

    def resolve(self, next, *args, **kwargs):
        return next(*args, **kwargs).catch(self.on_error)

But if an exception is caught, it no longer populates the errors field in query/mutation output. Therefore all errors are logged, there's no way to conditionally log exceptions.

This means the only solution is to create a logging filter like the following:

def skip_valid_exceptions(record):
    """
    Skip exceptions for errors only intended to be displayed to the API user.
    """
    skip: bool = False

    if record.exc_info:
        exc_type, exc_value = record.exc_info[:2]
        skip = isinstance(exc_value, valid_exceptions)

    return not skip

But this doesn't work either because record.exc_info is None whenever an error is thrown with Graphene, therefore it's not possible to conditionally filter out exceptions based on their type.

Is there a solution for this? Seems like it'd be a common issue but I've had trouble finding one. Something like this would be nice to be able to implement. Thanks in advance.

demeralde avatar Sep 22 '19 09:09 demeralde

Accidentally closed this issue.

demeralde avatar Sep 29 '19 09:09 demeralde

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Dec 29 '19 10:12 stale[bot]

Responding to remove the bot's label. I still have this issue and it's important.

demeralde avatar Jan 03 '20 22:01 demeralde

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar May 02 '20 22:05 stale[bot]

Commenting to remove the wontfix label, this still needs to be fixed. Just had someone comment on my StackOverflow post with the same problem.

demeralde avatar May 13 '20 00:05 demeralde

Hey @dspacejs , I removed the label. I also having problems with exact same issue for a long time. graphql-core package has other issues with error logging, i created a PR for that https://github.com/graphql-python/graphql-core-legacy/pull/269 but it's for the legacy version of the package and i don't think it will be ever merged. I agree on the importance of the issue you mention, but i think it would be better to revisit this after graphene 3 update.

ulgens avatar May 13 '20 04:05 ulgens

@ulgens thanks. What will Graphene 3 update exactly that will address this?

demeralde avatar May 19 '20 00:05 demeralde

@dspacejs I don't think the update has anything to address this issue, but if the issue still exist after the update, fixes on the core package will be more likely to get merged.

ulgens avatar May 19 '20 00:05 ulgens

Definitely interested in a solution for this myself - don't necessarily need to raise errors instead of logging them, but figuring out a better way for sentry to at least track them (vs needing to look at logs) would be super helpful.

mcabrams avatar Aug 05 '20 23:08 mcabrams

The problem is that report_error method from ExecutionContext class in graphql.execution.utilsis doing logger.error("".join(exception)) I have managed to fix this by monkey patch this class method.

from traceback import format_exception
from graphql.execution.utils import ExecutionContext, logger


def new_report_error(self, error, traceback=None):
    if not (
        hasattr(error, "original_error")
        and isinstance(error.original_error, IGNORED_EXCEPTIONS)
    ):
        exception = format_exception(
            type(error), error, getattr(error, "stack", None) or traceback
        )
        logger.error("".join(exception))

    self.errors.append(error)


# Monkey patch report_error method from ExecutionContext class
ExecutionContext.report_error = new_report_error

marcelombc avatar Oct 06 '20 12:10 marcelombc

Any updates on this issue? Running into the exact issue @dspacejs described

jonathankao97 avatar Aug 25 '21 09:08 jonathankao97

Would also like to have a solution for this issue

philipptrenz avatar Oct 11 '21 08:10 philipptrenz

No idea what's going on here. I think this issue should be prioritised, it's been over 2 years.

demeralde avatar Oct 11 '21 11:10 demeralde

I'm currently using the following logging filter to filter out GraphQLLocatedErrors, which get raised by the @login_required decorator of graphql_jwt when users are not authenticated:

class GraphQLLogFilter(logging.Filter):
    def filter(self, record):
        if record.msg and 'GraphQLLocatedError' in record.msg:
            return None
        return True

# settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
        },
    },
    'filters': {
        'graphql_log_filter': {
            '()': GraphQLLogFilter,
        }
    },
    'loggers': {
        'graphql.execution.utils': {
            'level': 'WARNING',
            'handlers': ['console'],
            'filters': ['graphql_log_filter'],
        },
    },
}

Nevertheless this exceptions should not end up in logging at all. I hope for a solution.

philipptrenz avatar Oct 11 '21 13:10 philipptrenz

Has this issue been fixed in the current version?

It would be nice to have more control over the verbosity of these errors. The stacktraces really worsen my logs readibility.

LMPombar avatar Feb 01 '24 12:02 LMPombar