-
-
Notifications
You must be signed in to change notification settings - Fork 269
Open
Description
We recently encountered some difficulty trying to update to v1. The cause is an undesirable interaction between ActsAsTenant::Sidekiq::Server
and the new ActsAsTenant::ActiveJobExtensions
(introduced in #319) - due to their different tenancy control approaches:
- https://github.com/ErwinM/acts_as_tenant/blob/v1.0.1/lib/acts_as_tenant/sidekiq.rb#L30 is opportunistic
- only influence tenancy if the expected pieces are present
- https://github.com/ErwinM/acts_as_tenant/blob/v1.0.1/lib/acts_as_tenant/active_job_extensions.rb#L9 is pessimistic
- clobber any tenancy if the expected pieces aren't present
Context
- Ruby 3.1.4
- Rails 7.1.2
- Sidekiq Pro 7.2.0
- codebase has both ActiveJob and Sidekiq::Job derived jobs
We use a rolling deploy strategy, so have both old and new code in active use for a period during release. The exceptions we encountered were due to:
- old code enqueuing jobs without passing through the new
ActsAsTenant::ActiveJobExtensions#serialize
(missing the"current_tenant"
key) - old code
ActsAsTenant::Sidekiq::Client#call
saving job tenancy in"acts_as_tenant"
hash - new code
ActsAsTenant::Sidekiq::Server#call
setting job tenancy from"acts_as_tenant"
hash - new code
ActsAsTenant::ActiveJobExtensions#deserialize
then nullifyingActsAsTenant.current_tenant
because the"current_tenant"
key was absent (clobbering the existing tenancy context)
Proposed Solution
I'd like to work on refactoring ActsAsTenant::ActiveJobExtensions#deserialize
such that:
- it was similarly opportunistic
- this would resolve issues during the crossover period
- perhaps short-circuit if
ActsAsTenant.current_tenant
is already set
Do these sound like reasonable improvements?
XavierMeunier, plicjo and ettaibi
Metadata
Metadata
Assignees
Labels
No labels