Skip to content
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

Closed
ckelly opened this issue Mar 10, 2021 · 3 comments · Fixed by #1448
Closed

Sentry Ruby/ Rails not capturing exceptions from rails/runner #1324

ckelly opened this issue Mar 10, 2021 · 3 comments · Fixed by #1448
Assignees
Milestone

Comments

@ckelly
Copy link

ckelly commented Mar 10, 2021

Describe the bug

exceptions in rails/runner jobs don't appear to be getting captured

To Reproduce
from project command line

./bin/rails runner 'Sentry.capture_message("test sentry runner capture")'

swapping back to sentry-raven (= 3.1.1) with below raven config and attempting:

./bin/rails runner 'Raven.capture_message("test old raven runner capture")'

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

  • Ruby Version: 2.7.1
  • SDK Version:
  • sentry-rails (= 4.2.2)
  • sentry-ruby (= 4.2.2)
  • sentry-sidekiq (= 4.2.1)
  • Rails 6.0.3.5
  • Sidekiq 6.1.3
  • Whenever 1.0.0 (cron job creation)

Current Sentry Config

This is not necessary but could be helpful.

Sentry.init do |config|
  config.dsn = 'MY_DSN'
  config.enabled_environments = %w[production staging]
  config.environment = "#{Rails.env}-console" if defined?(Rails::Console)
  config.breadcrumbs_logger = %i[sentry_logger active_support_logger]

  # set a uniform sample rate between 0.0 and 1.0
  config.traces_sample_rate = 0.2

end

Old Raven Config

Raven.configure do |config|
  config.dsn = 'MY_DSN'
  config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s)
  config.environments = %w[production staging]

  config.current_environment = "#{Rails.env}-console" if defined?(Rails::Console)
end
@st0012
Copy link
Collaborator

st0012 commented Mar 11, 2021

this is because sentry-ruby now sends events via the background worker by default (powered by a thread pool). and it's likely that the runner process exists before the worker sends out the event. you can work around this in 2 ways:

  1. use hint: { background: false } to force it send events synchronously. like Sentry.capture_message("test sentry runner capture", hint: { background: false }).
  2. set config.background_worker_threads = 0 if you want to disable the background worker all at once.

I'll find a way to avoid such problems. but for now, there doesn't seem to be a way for solving it cleanly.

@ckelly
Copy link
Author

ckelly commented Mar 11, 2021

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.

@ckelly
Copy link
Author

ckelly commented Mar 11, 2021

As a followup, we implemented the catch and sync-send in our runner job base class, and test exception reporting is much more consistent.

st0012 added a commit that referenced this issue May 20, 2021
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.
st0012 added a commit that referenced this issue May 20, 2021
* 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
@st0012 st0012 added this to the 4.5.0 milestone May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants