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

Rollbar.error has less context than uncaught exceptions #1151

Open
Paul-Yves opened this issue Jan 25, 2024 · 3 comments
Open

Rollbar.error has less context than uncaught exceptions #1151

Paul-Yves opened this issue Jan 25, 2024 · 3 comments

Comments

@Paul-Yves
Copy link

Uncaught exceptions in Rails are reported to rollbar with stacktrace and context such as request parameters.
However if we replace :

may_raise_exception()

by

begin
  may_raise_exception()
rescue TheExceptionClass => error
  return if should_fail_silently(error) # sometimes the exception should not be raised
  Rollbar.error(error)
end

I noticed a loss of context, I no longer have request param for example. I still have the proper stacktrace though so the part of the doc I read did not really helped me and I was wondering if it was a known issue and if there was something I could do to keep the maximum amount of context.

@PierreND
Copy link

I am also interested

@waltjones
Copy link
Contributor

Hi all, I haven't been able to reproduce this. When calling Rollbar methods with the default Rollbar instance, during the request lifecycle, the request context does get added to the request. If anyone has details that might help reproduce this, I'll try it.

In case it's helpful, here is some background on how the request context is added.

This is implemented in rollbar-gem using scopes. https://docs.rollbar.com/docs/ruby#the-scope

The initialization of the scope that is used with uncaught exceptions is here: https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/middleware/rails/rollbar.rb#L20-L22

That scope, containing the request and context, is added to the default Rollbar instance, and should be available for payloads anywhere Rollbar.log, Rollbar.error, etc. are called using the default Rollbar instance during the execution of the request. This also works when sending messages with no exception, e.g. Rollbar.info('Test message').

Exceptions to this:

The scope is set when entering the Rollbar middleware (request path) and removed when exiting (response path). Outside of this, the scope is cleared. This should work as expected for any Rollbar calls during the request lifecycle, but will be empty after the response is sent.

If multiple Rollbar instances are created, they will inherit the current scope of the parent instance at the time they are created, but their scope will not be updated later when the default instance is updated. Generally, their scope will not be automatically updated with each new incoming request.

Some job queues (Sidekiq, DelayedJob) have plugins that add their own scope. These are typically not executing during the request, though some senders have a synchronous option.

@Paul-Yves
Copy link
Author

Ok, I could not reproduce by directly putting this code in a controller, however I could reproduce when putting it in a sidekiq::job. I do not event need to be in a rescue, if I create a job directly calling Rollbar.error, I loose context such as the name of the job or the parameters it was called with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants