Closed jrjurman-jellyfish closed 1 year ago
Hey @jrjurman-jellyfish, there are a couple of ways you can accomplish this
You can use the capture
decorator with the default client, but have to import it from bugsnag.legacy
first:
from bugsnag.legacy import default_client
@default_client.capture(api_key='YOUR_API_KEY')
def a_function():
pass
@default_client.capture(api_key='YOUR_OTHER_API_KEY')
def another_function():
pass
Another way to do this is to use the configuration object returned by bugsnag_django.configure()
when creating new clients:
import bugsnag
from bugsnag import django as bugsnag_django
configuration = bugsnag_django.configure()
# make sure only one client installs the exception hook!
# see the note here: http://docs.bugsnag.com/platforms/python/other/reporting-handled-errors/#creating-clients
client1 = bugsnag.Client(configuration, install_sys_hook=True)
client2 = bugsnag.Client(configuration, install_sys_hook=False)
@client1.capture(api_key='YOUR_API_KEY')
def a_function():
pass
@client2.capture(api_key='YOUR_OTHER_API_KEY')
def another_function():
pass
This will make both clients share the same configuration object so any changes to one will affect the other, which may not be desirable. For example, you'll have to pass the api_key
to capture
every time it's called as otherwise they'll overwrite each other. You could clone the configuration object to get a copy for each client instead, if that's easier
Hope that helps! I'll also raise a task to look at if we can improve the docs around this
@imjoehaines thanks for these details, this looks exactly like what we need! I'll try one of these options this week and respond back on what works (or if I'm still running into issues). Documentation around this stuff would be awesome, but I'm sure this answer alone (in github issues) will do a lot of good for anyone else struggling!
Hi @jrjurman-jellyfish - I'm going to close this issue for now as I believe Joe has answered your question, but let us know if this doesn't work and we can reopen. Alternatively please feel free to write into support@bugsnag.com!
@imjoehaines @luke-belton
I tried the first method, using @default_client.capture(api_key='YOUR_API_KEY')
, and I'm seeing the snag go to our dedicated project (jellyfish-nessie), but I'm also seeing it show up for the original project that the default client is configured with (jellyfish-webapp):
Is this expected, and is there a way to configure the decorator such that we don't snag to both of these places?
What's happening there is that both the capture
decorator and our Django middleware are reporting the same exception
A simple way to fix it is to add a callback that sets skip_bugsnag
on the exception (this was added in v4.3.0 so make sure your bugsnag-python version is up to date!):
def skip_bugsnag(event):
event.original_error.skip_bugsnag = True
bugsnag.before_notify(skip_bugsnag)
This will prevent any event created from the same exception object from being sent more than once, so would stop the Django middleware from reporting the same error
Taking a step back though, I wonder if capture
is actually the wrong tool for the job. If you only want to route events to different projects based on where they were raised, it probably makes more sense to use a callback to do this because then you can route both unhandled and handled exceptions. Using capture
would only affect unhandled exceptions, so any manual calls to notify
would still go to the default project unless you also passed the api_key
every time
A callback to do this would look something like this:
def before_notify(event):
# if this event originates in 'get_meeting_breakdown_percentages', route it
# to a different project
if event.errors[0].stacktrace[-1]['method'] == 'get_meeting_breakdown_percentages':
event.api_key = '...'
bugsnag.before_notify(before_notify)
Describe the bug
I'm trying to setup decorators so that we can wrap different functions to route to different bugsnag projects. It seems (based on the documentation) the only way to do this is with created bugsnag clients (not the default client). However, when looking at the new inbox, we're not seeing the configuration that we expect (the release environment is wrong, we don't have a REQUEST tab, etc).
I believe these are all things that are wired by using the
.configure()
method on thefrom bugsnag import django
object, but there's no similar method for clients.Steps to reproduce
Environment
4.3.0
3.9.11
3.2.15
Example code snippet
In our setup, we have the following:
manage.py
hasIn a
bugsnag_clients.py
we haveIn a our code file we have
Below is a picture of the different results, the left side using the default bugsnag client, the right using the code above