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
We implemented multitenancy on a medium-large rails 4.2 app using apartment, and used this gem to allow jobs to be executed under the correct tenant. However, After using this for sometime, we are seeing Apartment::TenantNotFound errors for jobs scheduled in the future which, due to events in the normal application lifecycle, are run when the tenant has been deleted.
Because this gem is implemented to switch tenants before ActiveJob can set up callbacks and error handling, we are not able to handle the error using ActiveJob's built in error handling:
classApplicationJob < ActiveJob::Base# Would be ideal but does not workrescue_fromApartment::TenantNotFounddo |e|
# Handle error ...endend
Given the nature of jobs, it is expected that some of the data might not be available at the time of running the job. This gem should therefore not assume existence of the tenant when the job is running.
In our application, we are using this hacked version of code pulled out of this gem in the meantime:
It would be better if this were exposed as some kind of configuration; perhaps something like this:
Apartment::ActiveJob.configuredo |config|
# Assign handler as any object with a #call method# Examples:config.tenant_not_found_error_handler=->(e){ExceptionNotifier.notify(e)}config.tenant_not_found_error_handler=MyCustomErrorHandler.newend
The text was updated successfully, but these errors were encountered:
@Martin-Nyaga if you are still looking for a fix for this, you can try out https://github.com/uxxman/apartment_job. Since it uses ActiveJob's callbacks instead of overriding the base execute method like this library, you can use all ActiveJob's error handling options, e.g.
@uxxman thanks for pointing that out. The monkey patch above has worked for us for 2 years now with no issues, so we don't really have any incentive to change. But I do agree that I the around_perform implementation is much cleaner for error handling, I'll definitely keep it in mind.
We implemented multitenancy on a medium-large rails 4.2 app using apartment, and used this gem to allow jobs to be executed under the correct tenant. However, After using this for sometime, we are seeing
Apartment::TenantNotFound
errors for jobs scheduled in the future which, due to events in the normal application lifecycle, are run when the tenant has been deleted.Because this gem is implemented to switch tenants before ActiveJob can set up callbacks and error handling, we are not able to handle the error using ActiveJob's built in error handling:
Given the nature of jobs, it is expected that some of the data might not be available at the time of running the job. This gem should therefore not assume existence of the tenant when the job is running.
In our application, we are using this hacked version of code pulled out of this gem in the meantime:
It would be better if this were exposed as some kind of configuration; perhaps something like this:
The text was updated successfully, but these errors were encountered: