You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
So our Rails application has very low needs for a Job queue and as a result we use the default ActiveJob::QueueAdapters::AsyncAdapter (we are aware of the downsides of this adapter and they're fine for us as our needs are primarily only for maintaining caches which are expired anyways over time).
What we've noticed is that when exceptions are reported to Rollbar the scope seems to be incorrectly set with data from controller actions with the current user set (this doesn't make sense in the context of a Job execution).
I think what's happening is that the thread executes a controller action, which sets the scope, then the thread executes a job which retains the scope from the controller. Alternatively this could also be occurring when the work queue reaches it's capacity, in which case ActiveJob runs the job immediately in the caller thread.
The solution we currently have is to have a before_perform callback defined in ApplicationJob which calls Rollbar.reset_notifier!. Like this:
I'm not sure this is entirely correct because in the case where the queue is filled and the job is run in the caller thread then we should ideally restore the original scope after the job is performed, but I'm not sure how to do this and for the moment the solution above seems to work.
Do you have any thoughts on how best to resolve this?
The text was updated successfully, but these errors were encountered:
Hi,
So our Rails application has very low needs for a Job queue and as a result we use the default
ActiveJob::QueueAdapters::AsyncAdapter
(we are aware of the downsides of this adapter and they're fine for us as our needs are primarily only for maintaining caches which are expired anyways over time).What we've noticed is that when exceptions are reported to Rollbar the scope seems to be incorrectly set with data from controller actions with the current user set (this doesn't make sense in the context of a Job execution).
I think what's happening is that the thread executes a controller action, which sets the scope, then the thread executes a job which retains the scope from the controller. Alternatively this could also be occurring when the work queue reaches it's capacity, in which case ActiveJob runs the job immediately in the caller thread.
The solution we currently have is to have a
before_perform
callback defined inApplicationJob
which callsRollbar.reset_notifier!
. Like this:I'm not sure this is entirely correct because in the case where the queue is filled and the job is run in the caller thread then we should ideally restore the original scope after the job is performed, but I'm not sure how to do this and for the moment the solution above seems to work.
Do you have any thoughts on how best to resolve this?
The text was updated successfully, but these errors were encountered: