Replies: 1 comment 1 reply
-
Fixed it by extending protected function listenForJobsBeingProcessed(): self
{
app('events')->listen(JobProcessing::class, function (JobProcessing $event) {
if (! array_key_exists('tenantId', $event->job->payload())) {
return Tenant::current()?->forget();
}
$this->findTenant($event)->makeCurrent();
});
return $this;
} Anyone have a better solution? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi have a issue that I cannot seem to solve.
Along side this package we use mailcoach (works great BTW). Ive added the jobs for mailcoach to
not_tenant_aware_jobs
config so they wont cause any errors.The issue that I am experiencing is that, when another job which uses the multi tenancy feature the current tenant is stored for that process. The next scheduled campaign job sets the lock for (no tentant because its a cron-job) and dispatches its job to the queue. Because the process in the queue still has the tenant from the last job in memory, the cache-prefix key changes so the lock is not released because the queue clears the lock for the tentant_1 for example.
Another thing that broke our server is that the pending sends locks are also broken because the lock is for the last run tenant. So the throttle does not work in that case (our server was sending around 500 mails a minute and all the postmark feedback resulted in 84000 dispatched jobs).
Hope someone can help me out on this one!
Beta Was this translation helpful? Give feedback.
All reactions