patch_cli_runner was removed and it appears that raven no longer automatically sends django command errors

[budlight]

No description provided.

[mitsuhiko]

The default sys.excepthook should capture it. With which version of Django do you see it?

[currankaushik]

I don't have context for the original issue, but I think I may be encountering a similar problem, where exceptions in my management commands are not being captured by Raven.

As an example, I created a dummy command that just raises an exception in its handle method. In Raven versions <5.24.0, running the command via ./manage.py mycommand will present the exception message on the console, along with a message along the lines of Sentry is attempting to send 2 pending error messages, and the exception will make it to a dummy Sentry project I've set up. In Raven versions >=5.24.0, running the command simply dumps the exception message to the console, and the exception does not make it to the Sentry project.

I've tested this on Django 1.10.3 and 1.9.9 with the same results.

My Raven and logging configs are the following:

RAVEN_CONFIG = {
  "dsn": "<mydsn>",
}
LOGGING = {
  "version": 1,
  "disable_existing_loggers": False,
  "root": {
    "level": "INFO",
    "handlers": ["sentry"],
  },
  "handlers": {
    "sentry": {
      "level": "WARNING",
      "class": "raven.contrib.django.raven_compat.handlers.SentryHandler",
    }
  }
}

In addition, I have a custom client class (basically just a subclass of the DjangoClient that passes install_sql_hook=False). I have included it in my Django settings.py file as so:

SENTRY_CLIENT = "path.to.my.client"

I've tried to investigate this issue by seeing how the custom excepthook is set up in Raven here. It appears that sys.excepthook is only set when the Client is instantiated, but it doesn't seem like the Client is getting instantiated when the management command is run.

Please let me know if any additional information would be helpful.

[mitsuhiko]

Can you paste the actual traceback you get on the console? I wonder if Django now catches those exceptions itself and reports them.

[currankaushik]

Traceback (most recent call last):
  File "./manage.py", line 13, in <module>
    execute_from_command_line(sys.argv)
  File "/home/ck/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/home/ck/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 359, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/ck/env/lib/python2.7/site-packages/django/core/management/base.py", line 294, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/ck/env/lib/python2.7/site-packages/django/core/management/base.py", line 345, in execute
    output = self.handle(*args, **options)
  File "/home/ck/myproject/apps/test/management/commands/mycommand.py", line 6, in handle
    raise Exception("This is a dummy exception")
Exception: This is a dummy exception

[nikolaysm]

I am using djanog 1.9 and raven-5.32.0. raven no longer automatically sends django command errors

[nikolaysm]

With django 1.9 and raven==5.11.0. It works perfectly.

[spookylukey]

I am having similar problems, even when I add explicit logging calls in my manage.py - the messages are simply not being sent to Sentry:

    logger = logging.getLogger("manage.py")
    try:
        execute_from_command_line(sys.argv)
    except Exception:
        logger.exception(" ".join(sys.argv))

The "Configuring Raven for host" message does not appear on the console, nor any messages about sending messages to Sentry.

I have exactly the same behaviour as reported before - raven 5.23 works fine (including all the expected debug messages on the console), while 5.24 (as well as 5.32 and presumably all in between) does not work at all in this situation - whether with explicit logging calls or with sys.excepthook.

I have also tried with and without this call added to my manage.py, in case there was a problem setting up logging:

logging.config.dictConfig(settings.LOGGING)

but this made no difference.

For reference, I'm using Django 1.8.16. My logging set up is almost exactly the same as example one - https://docs.sentry.io/clients/python/integrations/django/#integration-with-logging (obviously I have a few extra things, but nothing that should affect this). I do not have a custom SENTRY_CLIENT

Is there any more information needed, or can we remove that tag? With latest Raven, and all supported Django versions, (Django 1.8 to 1.10), there doesn't seem to be any way to get Sentry integration with manage.py commands at all.

[spookylukey]

@mitsuhiko Can we have some attention to this? For Django, latest Raven client (up to 5.32.0) does not send any messages to Sentry outside request/response cycle.

[mitsuhiko]

@spookylukey i think this is largely just blocked because it's not clear how to solve it. Why does this not bubble up to the default except hook. Did this change in Django?

[spookylukey]

@mitsuhiko trying to debug this further, I can't reproduce my exact problem with a barebones Django project - namely, all logging through Sentry with client 5.24 and greater doesn't send messages. This ought to have been easier to debug, there must be some issue specific to my setup.

Debugging the default except hook thing might be harder, I don't know how to start with that.

[currankaushik]

@mitsuhiko After a brief investigation, it looks like the default sys.excepthook is not being successfully patched by raven when using management commands. As a result, raven's custom exception handling is not being triggered.

The patching of sys.excepthook appears to only happen when the raven Client is instantiated (

raven-python/raven/base.py

Line 216 in c69abaa

self.install_sys_hook()

). However, when a management command is run, no Client is being instantiated, which means that sys.excepthook remains unchanged (I checked whether the Client gets instantiated by just dumping a print statement in its __init__ method, and I also printed sys.excepthook from within the command's handle method and it displayed the default <built-in function excepthook> rather than the expected <function handle_exception at ...>).

Is there a way to force the Client to be instantiated as part of bootstrapping the management command?

[dcramer]

Since the conversation around this is sparse, here is the issue:

1. Old versions of Django bubbled up exceptions to the system
2. We originally patched Django's management commands to capture those exceptions
3. We then added sys.except_hook, which also captured those same exceptions
4. Due to duplicate errors, we removed the Django one-off (since sys.except_hook covered it)
5. Django's behavior changed and we're no longer correctly capturing exceptions

I'm not sure the most effective solution off hand, as its either "import raven to initialize it" or we once again have to monkey patch various things. I think one issue here is that our code isnt being imported at all here. It's possible its as easy as importing our runtime code in the management/__init__.py module.

[dcramer]

FYI I'm working on a patch for this. I think we can just hook apps in 1.7+ and runtime patch in older versions.

[cuu508]

Hello,

I see this issue is marked as closed. With recent Django and Raven versions, should the exceptions from management commands get reported to Sentry? Are there any additional steps to set them up?

I tested with this simple command:

from django.core.management.base import BaseCommand

class Command(BaseCommand):
    def handle(self, *args, **options):
        raise ValueError("hello from management command")

I got a traceback in console but nothing in Sentry website. I did not see "Sentry is attempting to send 1 pending error messages" output either.

I tested with Django 1.10.5 and 1.11, and with Sentry 6.0.0. Exceptions from request-response cycle do get reported.

[mattrobenolt]

I guess this was fixed on the 5.x branch, and also on master for 6.x, but we haven't yet cut 6.1 with this fix. Unsure what is blocking this tag though.

[cuu508]

Thank you for the quick response!
It indeed works if I install raven==5.33.0 so I will use that for now...