-
-
Notifications
You must be signed in to change notification settings - Fork 503
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
Sentry Ruby/ Rails not capturing exceptions from rails/runner #1324
Comments
this is because
I'll find a way to avoid such problems. but for now, there doesn't seem to be a way for solving it cleanly. |
thanks for the response. I think we'll capture the errors in our job base class and send them synchronously for now, and keep the rest of our stack async. |
As a followup, we implemented the catch and sync-send in our runner job base class, and test exception reporting is much more consistent. |
In some cases, being able to disable background sending globally is crucial for both users and the SDK itself. For example, Rails supports having different modes for running the application (server, console, runner, task...etc). In the runner or task mode, the process is killed right after script is returned, usually before the background worker have the chance to send the events. Here's an example issue: #1324 Although Rails provides callbacks for different modes, they're ran after the SDK initialization. And under the current setup, it's not possible to temporarily bypass background sending globally past the SDK initialization stage. So we can't disable the background workers in those callbacks. To solve the problem, this commit makes it possible to bypass background worker even after it's been initialized.
* Allow toggling background sending on the fly In some cases, being able to disable background sending globally is crucial for both users and the SDK itself. For example, Rails supports having different modes for running the application (server, console, runner, task...etc). In the runner or task mode, the process is killed right after script is returned, usually before the background worker have the chance to send the events. Here's an example issue: #1324 Although Rails provides callbacks for different modes, they're ran after the SDK initialization. And under the current setup, it's not possible to temporarily bypass background sending globally past the SDK initialization stage. So we can't disable the background workers in those callbacks. To solve the problem, this commit makes it possible to bypass background worker even after it's been initialized. * Update changelog
Describe the bug
exceptions in rails/runner jobs don't appear to be getting captured
To Reproduce
from project command line
swapping back to
sentry-raven (= 3.1.1)
with below raven config and attempting:sends messages to our sentry dashboard as expected.
(I've added development to environments in order to test locally, of course).
I've also verified that the jobs are getting the proper environment at runtime to match one of the expected/ enabled envs.
potential regression from raven fix - #325
Expected behavior
Exceptions/ messages log to our sentry project
Actual behavior
No exceptions or messages are being logged
Environment
Current Sentry Config
This is not necessary but could be helpful.
Old Raven Config
The text was updated successfully, but these errors were encountered: